Three months after a portfolio goes live, an occupancy report doesn't add up. Someone pulls the thread and finds a lease attached to a unit that was reassigned to a different property back in the spring. Nobody remembers touching that record. The person who ran the onboarding has three newer customers on their plate now. The person who'd know what the source data actually looked like on day one has probably moved teams, or moved on entirely.
By the time it's found, it's someone else's problem
An import that goes wrong at the point of import is, in a strange way, the easy case. The file fails, or a validation check catches it, or someone spots it in the first review pass. The cost is real but it's contained, it's still fresh, it's still the same person's desk.
The expensive version is different. It passes every check on day one. Correct data types, no missing fields, every value individually valid. It goes live, and it sits there quietly doing nothing wrong for weeks or months, until a report doesn't reconcile, or a resident calls in confused about a bill, or an audit sample happens to land on exactly the wrong row. By the time it surfaces, it's disconnected from the onboarding that created it, in time, and usually in ownership too. The team that handled that portfolio has moved on. Nobody's holding the context anymore, just the symptom.
It's rarely the value that's wrong
The lease-pointing-at-the-wrong-property case is the clearest version of this, because it's a relationship problem, not a data problem. Every field is correct. Property A is a real property. Unit 2210 is a real unit. The lease is a real lease. The only thing wrong is which of these points at which, and that kind of error doesn't trip a validation rule, because nothing about any single value looks broken.
It's not only relational mismatches, though that's the one that shows up most often in a portfolio's property-unit-resident structure. A different portfolio's rate table gets mapped in during import with one column off by a row, forty-two units on a two-bedroom rate that should have been the three-bedroom rate one tier up. Every charge posts cleanly. Every resident gets billed on schedule. It runs that way for two full billing cycles, technically valid, technically applied, quietly wrong, until someone reconciling revenue against the rent roll notices the math doesn't match what was promised at lease signing. Different mechanism, same pattern: passes every check, discovered somewhere else, long after the fact. And notice what kind of error this actually is: not one wrong unit, forty-two of them, all wrong the same way, for the same reason.
The question that matters here was never "is this record wrong." It's "how many others like it are there."
Why it's expensive to trace, and awkward to own
When this surfaces, fixing the one record someone found is the easy part, a two-minute change in the leasing CRM. The harder question is the one that edit doesn't answer: is this the only one. A relational mismatch might be a single lease that got mapped wrong. A rate table off by one row might be one unit, or it might be forty-two. Closing the ticket on the record you found feels like resolution, but without knowing where the error actually came from, there's no way to know whether the rest of the portfolio has more of the same thing sitting quietly, waiting for the next report that doesn't add up.
It's also awkward in a way that's easy to underestimate, and not just because nobody has time for it. The person investigating usually isn't the person who did the original import, it might be an auditor, a customer success rep fielding a confused resident, or someone on a completely different team who just needed a report to reconcile. Whoever it is, they're now facing a harder question than "what's the right value":
Did the customer's own export have this wrong to begin with, or did something in the mapping get it wrong on the way in?
That's not a detail. It determines whether this is a conversation with the customer about their data, or an internal problem that needs fixing regardless of what they sent, and getting that backwards is its own kind of expensive.
An audit finds one wrong record. Lineage finds the other forty-one.
What actually helps here
The fix isn't catching every possible error before go-live, that's not realistic for any process involving customer-supplied data, and pretending otherwise doesn't hold up. What actually matters once something's wrong is answering the two questions that determine what happens next: how far did it spread, and whose error was it.
Elvity keeps cell-level lineage on every value that moves through the platform, which source row it came from, what it was mapped from, when it landed. That turns both of those questions into something you can check instead of guess at. If a rate table got mapped wrong, lineage shows every unit that went through the same mapping rule, not just the one an audit happened to catch, so fixing the record and fixing the actual problem stop being two different projects. And it shows whether the value came in from the customer's own export as-is or changed somewhere in the pipeline, which is the difference between a conversation with the customer about their data and an internal fix nobody needs to explain to them at all. We've written before about why a scrollable chat transcript or a vague summary doesn't count as a real audit trail, and this is exactly the situation that distinction matters in: months later, with nobody around who remembers the original import, lineage is the difference between knowing the scope of a problem and just knowing about one symptom of it.
The honest version of this isn't "errors won't happen." It's that when one does, fixing the record you found stops getting mistaken for fixing the problem.
We wrote before about why the reconciliation work before go-live is so hard to predict in the first place. This is what happens when something gets through it anyway.
An error that passes every check on day one shouldn't turn into a guessing game about how far it spread.