Cross-Page Entity Resolution in Multi-Page Contracts and Legal Documents
Cross-page entity resolution is the process of matching a party name or defined term on page one of a contract to every place it reappears across dozens of subsequent pages, and most document AI pipelines get it wrong in ways that go unnoticed until someone acts on the bad output. This piece breaks down why the problem is layered rather than singular, how each layer fails, and what a system needs to get right before it can be trusted with a real contract.
Why entity resolution in multi-page contracts is hard
On the surface, the task looks simple. A contract names "Acme Incorporated" on the cover page, and somewhere on page 31 that same company appears as "Acme Inc." On page 44, it's "the Company." Somewhere in between, a definitions clause may have set up a shorthand that never touches the original name at all. A human reader tracks this without effort, because a human reader holds the whole document in mind at once. A parsing pipeline processing pages, or even chunks of pages, does not have that luxury unless someone builds it in.
What makes contracts harder than general-purpose cross-document matching is that the aliasing is deliberate. Legal drafting exists to compress: instead of repeating "Acme Incorporated, a Delaware corporation with its principal place of business at..." forty times, the drafter defines "the Company" once and uses it everywhere after. A naive matching system sees "Acme Incorporated" and "the Company" and reads two unrelated strings. It has no way of knowing they refer to the same legal party unless it understands how defined terms work in legal drafting, which is a structural convention, not a naming pattern.
Then there's everything the flat text throws away. Clause hierarchy, cross-references, exhibit relationships: these carry meaning. An indemnification clause on page 19 that references "the Purchaser as defined in Section 2.1" is making a structural claim. Strip that structure out, which is exactly what happens when a document gets converted into a plain text stream, and you lose the scaffolding the resolution system needs.
Length compounds all of this. A short confidentiality agreement running a few pages has limited surface area for alias drift or OCR error. A 60-page credit agreement with a dozen exhibits has enormous surface area, and errors don't cancel out as the page count grows, they accumulate across the document's expanding surface area. The problem runs in four layers: parser quality, structure preservation, alias tracking, and graph construction. Each layer can fail on its own, and a failure early in that chain doesn't just cause one bad extraction. It corrupts everything built on top of it.
How parser quality sets the ceiling for everything downstream
Everything starts with what the parser hands off, and if that's wrong, no amount of clever matching logic downstream fixes it. A misread digit in a payment term, a single OCR mistake, becomes ground truth for every tool that touches the document after that. There's no later stage where someone checks the original page again.
The bigger failure mode is structural. When OCR flattens a contract page into a single stream of text, it takes the headings, the clause numbering, the nested subsections, and the cross-reference markers with it. None of that survives a naive text dump. And once it's gone, entity resolution is starting from a document that has already lost the very structure it needs to do its job.
Layout-aware parsing for legal documents has specific, non-negotiable requirements. Multi-column pages need to be read in the right order, not left-column-then-right-column-mashed-together. Clause numbering and subsection nesting need to survive intact, because "Section 4.2(b)" only means something if the clause is still nested under its parent subsection and section. Tables need row-column relationships preserved, not flattened into a soup of cell values. Footnotes and appendices need to remain associated with their surrounding document context, not float free as orphaned text blocks.
Handwritten amendments, scanned exhibits, and faxed agreements with margin notes occur constantly in real estate closings, legal services, and finance. Production-grade systems tend to run in the low-to-mid 90s percent accuracy range on printed handwriting, but drop substantially on cursive. That gap means confidence flagging on these regions is a critical safeguard between a silently wrong extraction and a human catching it before it matters.
Defined terms, aliases, and their effect on a resolution system
Defined terms are the point of legal drafting. They're the point of legal drafting. A contract's recitals or definitions section will formally establish "Acme Incorporated" and then refer to it as "the Company" for the rest of the document, on purpose, to keep the prose readable. Standard text-matching tools see this and read it as noise, or miss it entirely.
The reason fuzzy matching alone can't bridge this gap is straightforward: "Acme Incorporated" and "the Company" share zero surface tokens. Run a string similarity score between them and it comes back near zero, even though any lawyer reading the contract knows they're the same entity. A tool like rapidfuzz's token_set_ratio function handles reordered words and abbreviation differences well, it'll correctly match "Inc." to "Incorporated" without trouble, but it has no mechanism for connecting a formal name to a definitional shorthand that doesn't share any words with it. Embedding-based similarity, using something like a sentence-transformer model such as all-MiniLM-L6-v2 (117 million parameters, per The Neural Base), can get closer by capturing semantic proximity rather than surface overlap. But even that only works if the definitions section itself was correctly parsed and associated with the term it defines in the first place.
That's the real dependency here, and it's easy to underestimate. If the definitions clause gets dropped, reordered, or split across a page break by a parser that flattens structure, the alias map the rest of the document relies on never gets built. Everything downstream inherits that gap.
Not all aliases behave the same way, either. Formal defined terms introduced with language like "hereinafter referred to as," or set off in parentheses, are the most tractable case. Abbreviated forms, "Acme Inc." versus "Acme Incorporated," are addressable with fuzzy matching alone. Pronoun-like role references, "the Licensor," "the Borrower," require resolution that understands document roles. And exhibit or schedule references sometimes rename or re-scope a party entirely within a limited section of the document, which means an alias that's valid on page 40 might not apply the same way by page 55.
The matching strategies available and their breaking points
No single matching technique covers the full range of alias behavior in a contract, and understanding where each one fails is more useful than knowing where it succeeds.
Fuzzy string matching, using something like rapidfuzz's token_set_ratio, handles a specific and useful slice of the problem: abbreviation variants, OCR transpositions, word-order differences. The simpler fuzz.ratio() function is sensitive to word order in a way that breaks on common contract variants, so token_set_ratio is the right tool for this specific job. But fuzzy matching has a hard ceiling: it cannot recognize semantic equivalence. "Apple Computer" and "Apple Inc." score low on a string basis. Defined-term aliases, as covered above, score close to zero. Fuzzy matching is necessary but nowhere near sufficient.
Embedding-based resolution picks up some of that slack. A lightweight model like all-MiniLM-L6-v2 can capture semantic similarity that pure string comparison misses entirely, including language variation and some transliteration cases. But it comes with a scale problem: naive pairwise comparison across every entity candidate is quadratic, and once a corpus grows large enough, that compute cost becomes prohibitive without approximate nearest-neighbor indexing, using something like FAISS or hnswlib, to cut the search space down. And embeddings have their own blind spot: two entities that are semantically distinct but occupy similar space, like "the Licensor" in one contract versus a different "Licensor" in an unrelated agreement, can get confused precisely because they're structurally similar roles.
The production answer, in most working systems, is a hybrid: fuzzy matching handles surface-level variation, embeddings handle semantic drift, and a weighted combination of the two scores determines the canonical match. This only works efficiently if embeddings get cached rather than recomputed for every candidate pair in a batch, since recomputation introduces order-of-magnitude slowdowns that make the approach impractical at any real volume.
Graph-based resolution is the fourth tool, and it earns its place when relational signals are more useful than text similarity. An approach like GraphER, which combines graph differential dependencies with graph neural networks, becomes relevant when entities share structural context, a shared registered address, overlapping signatories, a common parent company, that string and embedding methods can't see. Recent academic work has also started probing how large language models perform at entity matching directly: recent academic work has examined whether matching, comparing, or selecting is the better LLM strategy for these tasks, finding that the choice of strategy meaningfully changes results. Graph methods tend to earn their keep exactly where string and embedding signals go ambiguous but relational context stays strong.
Building the unified entity graph across a full contract
A unified entity graph is the data structure that ties everything above together: one canonical ID per real-world entity, with every alias mention across every page, section, and exhibit mapped back to it. That's the actual deliverable of cross-page entity resolution. Everything before this point exists to feed it.
The graph has to hold more than party names. It needs defined-term aliases and their scope, since some definitions only apply within a specific exhibit and don't carry over to the main body. It needs role relationships, since the same legal entity frequently appears under different labels in different sections, appearing as "Licensor" in one clause and "Counterparty" in another. It needs the cross-references between clauses that implicitly link entities, like an indemnification clause that references a party defined all the way back in Schedule A. And it needs temporal scope: amendment dates, notice periods, renewal terms, all of which affect which version of an entity is actually operative at a given point in the contract's life.
None of this is buildable without the earlier layers doing their job first. Graph construction depends entirely on structure-preserving parsing, on section headings and clause hierarchy and exhibit associations surviving intact. Without that, the graph builder simply doesn't have the relational signals it needs to work with. This is the clearest illustration of why the problem is layered rather than modular: you cannot swap in a better graph algorithm to fix a parsing failure that happened three steps earlier.
When the graph is wrong, the failure doesn't announce itself. Downstream agents acting on a corrupted entity graph make decisions about the wrong party, and the output still looks clean and structured. Nothing about a wrong canonical mapping looks broken from the outside. That's what makes it dangerous: a bad merge or a missed alias doesn't throw an error, it just quietly produces a confidently wrong answer.
Why confidence scoring and explainability matter in production
Model-internal confidence scores tell you how certain a model was about its own output. They do not tell you whether that output matches the actual document. Those are two different questions, and conflating them is how extraction errors slip past every checkpoint and land in front of a person who has no reason to double-check them.
Reconstruction-as-validation, sometimes referred to under a framework like RaV-IDP, is one approach here. The idea: after extraction, a reconstructor renders the extracted representation back into something comparable to the original document region, and a comparator scores how faithful that reconstruction is against the unmodified source crop. That score is grounded in the actual document. Different entity types get scored with different metrics: tables get evaluated with structural similarity measures and structural character error rate, text gets scored for fidelity against the source region, images get checked with perceptual hashing, sharpness, and caption consistency. A fidelity score of 0.983 on a text block signals close correspondence to the source. A score of 0.322 on a table signals real structural divergence, and both numbers are interpretable by someone with zero background in the underlying model.
If a fallback mechanism nudges a table's fidelity score from 0.322 up to 0.387, that improvement should not cause the system to relabel the entity as passing. The low-confidence flag needs to be set by a fixed threshold, not by whether some fallback was attempted along the way. Otherwise the confidence signal becomes a record of effort rather than a record of accuracy.
Asking a large language model to explain why it made a particular entity match, and then treating that explanation as an audit trail, is not a reliable practice. An arXiv preprint examining whether LLM self-explanations for entity resolution can be trusted gets at exactly this problem. The model that produced the extraction is not a neutral party checking its own work. Real explainability in a contract context means the ability to trace a canonical entity assignment back to the specific source clauses, the page coordinates, and the match scores that produced it. Not a narrative explanation generated after the fact.
The agentic pipeline architecture that holds all these layers together
Every layer discussed so far, parsing, alias tracking, graph construction, confidence scoring, has to live inside some kind of pipeline architecture, and the shape of that architecture determines whether the layers work together or just sit next to each other. The common pattern runs five stages: ingestion, classification, extraction, validation, and storage, with an agent monitoring incoming documents, processing them without a human kicking off each step, flagging low-confidence results for review, and storing both the source document and whatever got extracted from it.
What separates this from older intelligent document processing setups is what happens when a document doesn't match expectations. Traditional IDP runs a fixed sequence of steps built around a template. When a contract's layout deviates from that template, even slightly, the pipeline either fails outright or kicks the whole document to a human, and every new document type requires someone to build a new template from scratch. An agentic system replaces that fixed sequence with something closer to a reasoning loop: the agent reads the document, decides what to retrieve next, checks its own result against a validation step, retries if confidence comes back low, and carries state forward across each step rather than treating every step as independent.
That state-carrying is precisely what makes cross-page entity resolution possible in the first place. The agent holds the alias map and the entity graph in memory as it moves through the document, page by page, rather than processing each page in isolation and hoping the pieces line up later. Schema optimization, where a system automatically experiments with different prompt and configuration variants to find what extracts a given document type reliably, cuts down what used to be weeks of manual tuning into a matter of days. That's a meaningful shift in how fast a new contract type can go from unfamiliar to production-ready.
None of it works, though, if the pipeline gets the very first step wrong. Before entity resolution can even start, a multi-document data room has to be split correctly into individual contract units. A splitting error that merges two separate contracts into one processing unit, or fragments a single contract across two, corrupts the entity graph before any matching logic gets a chance to run. Everything downstream inherits that mistake the same way it inherits an OCR error: silently, and without an obvious point of failure.
Contract AI tools in 2026 and their place on this spectrum
By 2026, contract AI tools cluster into a wide range along the maturity spectrum laid out above, and the split largely comes down to how many of these layers a given tool actually addresses versus how many it assumes away. Some products focus narrowly on extraction accuracy for individual fields, clause dates, dollar amounts, party names, without building a persistent entity graph that tracks aliasing across the full document. That's useful for single-page forms and considerably less useful for a 60-page credit agreement with a dozen exhibits and three amendments.
Other tools take the layered approach seriously: structure-preserving parsing feeding an alias-tracking layer, feeding a graph builder, with confidence scoring and source-traceable explainability wrapped around the output. That's a materially harder system to build, and it shows in how these tools handle documents that deviate from a clean, boilerplate template. The gap between the two approaches is not visible in a demo with a tidy sample contract. It shows up on page 44 of a real one, when "the Company" needs to resolve to the right entity and nothing in the pipeline flags that it didn't.
The direction of travel across the field points toward agentic architectures with reasoning loops and persistent state, rather than fixed-template extraction. That shift tracks with the broader move in document AI toward systems that can handle documents they weren't specifically built for, rather than systems that need a new template every time a contract looks slightly different from the last one.
