A lease record says the monthly rent is $2,100. The executed PDF says $2,200. The PMS says the lease ends on June 30. A signed addendum extends it through July 31.
A conventional migration does not create those discrepancies. It can make them harder to see by copying the database values into a clean new system, where they inherit the credibility of the new platform.
This is data drift: the structured record and the documents supporting it no longer agree.
The database is operational, not automatically authoritative
Property management software drives billing, renewals, notices, deposit workflows, and reporting. Its structured fields have to be treated seriously because the target system will act on them.
But those fields are maintained by people. Amendments arrive by email. Addenda are uploaded without updating the lease record. Dates are copied from the wrong document. A correct value can become stale while still passing every database constraint.
A migration can reproduce the legacy database perfectly and still carry the wrong operational instruction forward.
There may be more than one source of evidence
| Evidence source | What it contributes | Common limitation | Migration treatment |
|---|---|---|---|
| PMS database | Current structured values used by workflows | Can be stale, mistyped, or disconnected from later documents | Compare rather than assume |
| Executed base lease | Original signed terms | May be superseded by addenda or renewal agreements | Extract values with document and page evidence |
| Signed addendum | Later changes to specific terms | Precedence and effective date require context | Link to the base lease and apply approved precedence rules |
| Email or internal note | Operational context and pending changes | May not be executed or legally controlling | Preserve as evidence; do not silently override signed terms |
| Ledger activity | What was actually charged and paid | Can reflect an error repeated over time | Use as corroborating evidence and flag conflicts |
Document verification is a comparison system
OCR can locate text in a PDF. Document models can identify likely dates, rent amounts, deposits, recurring charges, and renewal terms. The useful output is not simply a new set of values. It is a field-level comparison with evidence attached.
For each target field, the pipeline should retain:
- The database value and source record ID.
- The extracted document value, document type, page, and location.
- The extraction confidence and any competing candidates.
- The comparison result: match, delta, missing, or ambiguous.
- The approved action and the person or rule that approved it.
A signed PDF is evidence, not a magic answer key
Documents can be incomplete, poorly scanned, unsigned, superseded, or internally inconsistent. A lease package may contain several amounts: base rent, prorated first-month rent, concessions, pet rent, utility charges, and renewal pricing. A date can refer to execution, commencement, possession, expiration, or notice.
That is why AI should propose a value with context rather than overwrite the database automatically. Strong extraction confidence does not resolve which document controls or whether a later addendum supersedes the base agreement.
Sample review cannot characterize every discrepancy
Manual sampling is useful for testing a process, but it cannot prove that unreviewed leases agree with their database records. Automated comparison can evaluate a broader set of documents and route only mismatches and low-confidence fields to specialists.
Coverage still needs to be measured honestly. The team should report how many expected leases were found, how many documents were readable, how many fields were extracted, how many comparisons matched, and how many records entered an exception queue. A document that was missing or unreadable is not “verified.”
Not every delta is an error
A mismatch starts an investigation. It does not determine the winner. Useful exception categories include:
- Probable database error: signed document evidence is clear and no later agreement conflicts.
- Probable extraction error: OCR or classification selected the wrong text region.
- Document precedence issue: the base lease and addendum both contain valid but time-dependent values.
- Operational exception: the ledger or an approved concession explains a difference.
- Missing evidence: no supporting document can be linked reliably.
The review interface should show the structured value and highlighted document region side by side. That gives the reviewer enough context to decide without reopening folders and searching PDFs manually.
Lineage makes corrections defensible
When the migration changes a rent amount, deposit, or lease date, the final target value should remain connected to the evidence used to approve it. The lineage record should identify the legacy field, supporting document, extracted region, comparison outcome, reviewer decision, and target field.
This does not replace legal interpretation or compliance review. It makes the data decision reconstructable when a resident, owner, auditor, or implementation team later asks why the value changed.
Move verified decisions, not inherited assumptions
Elvity’s PropTech data onboarding platform connects lease records to their supporting documents, extracts field candidates with evidence, compares them against structured source values, and routes discrepancies into a reviewable exception workflow. Approved target values retain their source lineage.
The objective is not to declare every PDF correct or every database wrong. It is to stop disagreement from passing through migration unnoticed.
A new system should begin with documented decisions about the data it will operate on—not silent trust in whichever source happened to be easiest to import.
Find lease discrepancies before go-live
See how Elvity compares structured records with supporting documents and keeps every approved correction tied to its evidence.