Entity resolution is the process of determining when two records that look different actually refer to the same real-world thing, and when two records that look similar refer to different things. In lease reconciliation across systems, it is the step that decides whether "ACME Corp," "Acme Corporation," and "ACME Corp. LLC" are one tenant or three, and whether Suite 200 in the property management system is the same space as Unit 2A in the accounting ledger. Reconciliation compares values between systems, but that comparison is meaningless until the records on each side are correctly matched. Entity resolution comes first. Everything downstream inherits its errors.
Why Cross-System Reconciliation Is Hard
Lease data rarely lives in one place. A single asset may have leases in a property management system, charges in an accounting platform, abstracts in a lease administration tool, and terms in the original documents. Each system was populated by different people at different times, and none of them shared a common identifier for tenants, properties, or spaces. The result is that the same lease exists as four records with four different spellings, four different keys, and often four slightly different values.
Reconciliation assumes you can line up a record in one system against its counterpart in another. When the identifiers do not match, that assumption breaks. The core difficulty is not comparing values. It is knowing which values to compare.
System | Typical primary key | What it optimizes for |
Property management | Internal unit ID | Operations and billing |
Accounting | GL account or entity code | Financial reporting |
Lease administration | Abstract record ID | Term tracking |
Source documents | None, free text | Legal accuracy |
Because no shared key exists, matching has to be inferred from the data itself: names, addresses, square footage, dates, and amounts. That inference is entity resolution.
The Three Entities That Need Resolving
Cross-system reconciliation involves three distinct entities, and each fails in its own way. Tenants, properties, and spaces must all be resolved before any charge or term can be compared. Treating them as a single problem obscures the specific patterns that cause mismatches.
Tenants
Tenant names are the least standardized field in commercial real estate data. The same tenant appears as a legal entity name in one system, a trade name in another, and an abbreviation in a third. Corporate structure adds a layer: the entity on the lease may be a single-purpose subsidiary while the operating brand is the parent. Assignments and subleases mean the tenant of record can change while the occupant does not.
Properties
Property identity seems simple but fractures on address formatting and portfolio structure. One building can have multiple street addresses. A property in accounting may be a legal entity that owns several buildings a property manager tracks separately. Reconciling at the wrong level of the property hierarchy produces systematic errors.
Spaces
Suites and units are renumbered, combined, and subdivided over a property's life. Suite 200 becomes Suites 200 and 210 after a demising wall. Two adjacent units combine into one for a larger tenant. If the systems captured these changes at different times, the space records will not align even when the tenant and property do.
Entity | Primary failure mode | Signal that resolves it |
Tenant | Name variation, corporate structure | Legal name, address, lease dates |
Property | Address formatting, hierarchy level | Geocoded address, parcel |
Space | Renumbering, combination, subdivision | Square footage, floor, adjacency |
Deterministic and Probabilistic Matching
There are two broad strategies for matching records, and mature reconciliation uses both. Deterministic matching applies exact rules: two records match if a chosen field or combination of fields is identical. Probabilistic matching scores similarity across multiple fields and matches when the combined score passes a threshold. Each has a place.
Deterministic matching is fast, explainable, and correct when a reliable shared key exists. It fails silently when keys are absent or inconsistent, because a single character difference produces a non-match. Probabilistic matching tolerates the variation that pervades lease data, but it introduces the risk of false matches and requires a threshold that trades false positives against false negatives.
Property | Deterministic | Probabilistic |
Basis | Exact field equality | Weighted similarity score |
Handles name variation | No | Yes |
Explainability | High | Moderate |
False match risk | Low | Tunable |
Best for | Clean shared keys | Messy real-world data |
The practical pattern is layered: apply deterministic rules first to match the records that share reliable keys, then apply probabilistic matching to the remainder. The deterministic pass clears the easy cases cheaply and leaves the ambiguous ones for scored comparison.
Blocking and the Scale Problem
Comparing every record in one system against every record in another is quadratic. For a large portfolio, the number of pairwise comparisons becomes impractical, and most of those comparisons are obviously irrelevant. Blocking is the technique that makes entity resolution tractable at scale by limiting comparisons to records that could plausibly match.
A blocking key groups records into buckets, and matching only compares records within the same bucket. A good blocking key is cheap to compute and rarely wrong for true matches. Property or ZIP code is a common block: a tenant in one building will not match a tenant in another, so there is no reason to compare across properties.
Blocking key | Reduces comparisons by | Risk |
Property or building | Large | Misses cross-property assignments |
ZIP or submarket | Large | Groups too coarsely in dense areas |
First characters of name | Moderate | Misses name variants at the start |
Square footage band | Moderate | Misses remeasured spaces |
Blocking trades completeness for tractability. A blocking key that is too aggressive will place true matches in different buckets and miss them. The mitigation is to block on more than one key and take the union of candidate pairs, so a match missed by one blocking key can be caught by another.
Choosing the System of Record
Once records are matched, reconciliation surfaces disagreements: the two systems hold different values for the same field. Resolving those disagreements requires a rule for which system to trust, and that rule should be decided in advance rather than case by case. Without a designated system of record, reconciliation devolves into ad hoc judgment that is neither consistent nor auditable.
The right system of record depends on the field. The source document is authoritative for contractual terms because it is the contract. The accounting system is authoritative for what was actually billed and collected. The property management system is often authoritative for current operational status such as occupancy. Assigning authority by field rather than by system produces the most defensible result.
Field type | Authoritative source | Reason |
Contractual rent and dates | Source document | It is the agreement |
Amounts billed and paid | Accounting system | Records actual transactions |
Current occupancy status | Property management | Tracks operations |
Abstracted terms | Verify against document | Abstract is a copy, not the source |
The key discipline is that an abstract or a rent roll is a derived record, not a source. When a lease administration system disagrees with the document, the document wins, because the administration record was itself transcribed from the document and may carry a transcription error.
Handling Match Failures
No entity resolution process matches everything correctly. Some records have no counterpart because a lease exists in one system and not another. Some have several plausible counterparts. A reconciliation that hides these failures produces false confidence. A reconciliation that surfaces them as explicit exceptions produces trustworthy output.
Match outcomes fall into categories, and each needs a defined disposition rather than a silent guess.
Outcome | Meaning | Action |
Confident match | One clear counterpart | Reconcile values |
No match | Record exists in one system only | Investigate missing record |
Multiple candidates | Several plausible counterparts | Route to human review |
Low-confidence match | Score near threshold | Flag for verification |
The most dangerous outcome is the low-confidence match accepted as confident. If the threshold is set to maximize matches, borderline pairs get matched and their value differences get reconciled as if the records were the same entity, which silently merges two tenants or two spaces. Setting the threshold conservatively and routing the borderline cases to human review is safer than maximizing the automatic match rate.
Where AI Changes the Economics
Entity resolution has historically been labor-intensive because the matching signals live in unstructured text and require judgment. Reading a lease to determine the legal tenant name, comparing it to a name in an accounting system, and deciding whether corporate structure explains the difference is exactly the kind of task that resisted automation. AI-assisted extraction and matching shift this.
Language models can read source documents to extract the governing entity names, addresses, and terms directly, rather than relying on the transcribed values in downstream systems. They can compare variant strings with an understanding of common corporate naming patterns, abbreviations, and entity suffixes that rigid string-distance measures miss. This improves probabilistic matching on the fields that matter most, tenant names and property descriptions, while the deterministic and blocking machinery still handles scale. The judgment cases, genuinely ambiguous corporate structures or contested spaces, remain human decisions, but the volume routed to humans drops.
The gain is largest where the matching signal is buried in prose rather than sitting in a structured field. A guaranty clause may name the parent entity that stands behind a subsidiary tenant, an assignment provision may record a change in the tenant of record, and a recital may state the legal name that a downstream system abbreviated. Rigid matching never sees these signals because they are not in the fields it compares. Reading the document surfaces them. The effect is that two records a string comparison would reject as different can be correctly matched once the corporate relationship stated in the lease is taken into account, and two records a loose comparison would wrongly merge can be kept apart once the documents show they are distinct entities that happen to share a name.
Conclusion
Reconciling leases across systems is often described as a comparison problem, but the hard part comes before any comparison: deciding which records refer to the same tenant, property, and space when no shared identifier exists. That is entity resolution, and it fails in distinct ways for each entity type. The workable approach layers deterministic matching for clean keys over probabilistic matching for the messy remainder, uses blocking to stay tractable at scale, assigns a field-level system of record so disagreements resolve consistently, and surfaces match failures as explicit exceptions rather than silent guesses. AI improves the matching signals drawn from unstructured documents, but the discipline is the same: resolve the entities correctly first, because every reconciled value inherits the correctness of the match beneath it.