Ledgers arrive from many different senders, each in its own format. From them, an automated pipeline assembles a figure that a professional then personally certifies. Extraction across all those formats is the visible engineering problem. The figure is the dangerous one. If it is overstated, the person whose signature is on it carries the consequences, and in a legal setting an overstated demand is a problem in its own right, quite apart from the arithmetic.
A ledger's total answers the ledger's question, and a claim asks a different one.
A ledger is a running record. Each entry says that something was charged or paid, on a date, for an amount, and the balance at the bottom is the arithmetic consequence of every entry above it. That balance is correct by construction, in the sense that it faithfully reflects what the sender's system recorded under the sender's own rules about what to charge.
A certified figure asks something else: of everything recorded here, what may be claimed. Answering it takes operations the ledger never performs. Each line item is classified into categories that the governing rules treat differently. A set of exclusion rules is applied, and many of those rules are conditional on facts found elsewhere, such as which agreement governs the relationship or which programme applies. Then what remains is summed. The result can differ from the ledger's balance even when every single line of the ledger is correct.
Because the figure is derived, it needs provenance, a record of where each part came from. Data engineers call this lineage. Every output keeps a pointer to the inputs and the rule that produced it, so anyone can walk back from the number to the evidence. Lineage turns a challenge from an argument into a lookup. It also points at the third outcome a rule-based system can have. Besides a result and an error, a well-designed system can abstain when it reaches a case its rules do not cover. Where a person signs the output, abstaining is often the most valuable thing the system does.
A ledger is a faithful record of what was charged and paid. The figure that may be demanded is a different quantity. It is built from the same line items under rules the ledger knows nothing about, and some of those rules depend on which agreement governs, which programme applies, or which addendum is bound in. Extraction accuracy measures the pipeline against the document. The document is not the thing being certified.
Figure pipelines usually fail by being right about the wrong document.
Teams building extraction systems measure extraction, because it is the hard technical problem in front of them and it has a clean metric. A pipeline can score perfectly on that metric and still produce a figure nobody should sign, because the metric compares output to source, and the source was never the target.
The other failure is confidence on unfamiliar ground. A rule engine with no way to abstain treats every case as one it knows. When a case turns on a condition that was never encoded, the engine applies whatever default it has, produces a clean number, and gives nobody any reason to look twice.
The reflex, and the fix.
Extract robustly and read the stated total
It is the visible engineering, progress on it is easy to measure, and the total is printed right there on the page.
The stated total can include amounts that a governing instrument excludes. A perfectly extracted total then becomes a perfectly extracted overstatement, signed by someone who trusted it.
Rebuild the figure from classified line items
Classifying every line item, encoding each exclusion rule together with its conditions, and storing the derivation of every number.
A figure that can be defended line by line, with the rule that admitted each component kept beside it.
The number on the ledger and the number that may be claimed are different quantities, so the pipeline derives the second and never simply reads the first.
Take the line items and leave the total
The stated total belongs to the sender's system and reflects that system's rules. Extracting the individual items is what makes a different derivation possible.
Classify every charge
Each item is placed into the categories the governing rules actually distinguish. The forms and the rules treat those categories differently, so a charge that lands in the wrong one changes the figure.
Supply the conditions from outside
The conditions that decide an exclusion usually live outside the ledger: the governing agreement, the applicable programme, any bound addendum. They are inputs to the pipeline. Nothing tries to infer them from the document being processed.
Keep the derivation with the figure
Every figure carries the items it was built from and the rule that admitted each one. A challenge is answered by showing the trace.
A third outcome besides an answer and an error
When a case depends on a condition with no encoded rule, the pipeline produces neither a figure nor an error. It stops and hands the case to a person. Where someone certifies the output, a stop costs a review, and a confident wrong figure costs considerably more.
What each choice cost, and what it bought.
AExtracting the components and setting the total aside
The total is the easiest value on the page to find and the hardest to argue with. Extracting every line item across many senders' formats is considerably more work, and it multiplies the parsing surface. It is also the only route to a figure derived under rules other than the sender's. Reading the total and subtracting exclusions sounds like a shortcut, but it still needs the components to know what to subtract, and it inherits whatever the sender's system silently folded into its balance.
BTreating governing conditions as inputs
It is tempting to have the pipeline infer the governing agreement or programme from clues in the ledger, because that keeps the workflow to a single document. The clues are unreliable and the inference would be invisible to the person signing. Making the conditions explicit inputs means someone has to supply them for each case, which adds a step. It also means every exclusion that was applied traces back to a condition a person actually stated.
CStoring the derivation with every figure
Keeping a trace from each figure back to its items and rules costs storage and design effort, and it forces the classification and rule logic to be explicit enough to record. What it buys is a figure that can be defended line by line when it is questioned, and a way to find every affected figure when a rule turns out to have been encoded wrongly.
DDesigning the stop in from the start
In a demonstration, a stop looks like a failure, and a system that always produces a number looks more finished. For a certified output the asymmetry runs the other way. A stop costs one review. A confident figure built on an unencoded condition costs the person who certified it, and it stays invisible until someone challenges it. So the stop is a normal outcome with its own route to a person, and it was part of the architecture before any rules were encoded.
A single headline number hides where a system fails. This work was scored on the dimensions that actually decide whether it holds in production, measured on real, held-out cases rather than the demo path.
No measured figures are published for this engagement. Outcomes are described qualitatively.
A robust extractor that reads each ledger's own total, is correct about the document, overstates the claim, and leaves no trace of which line caused it.
A figure rebuilt from classified line items under encoded exclusion rules, with the governing conditions supplied as inputs, the derivation stored beside every number, and a stop on any case the rules do not cover.
What it owns, and what it hands to a person.
Rebuilding by rule covers the rules that have been encoded and nothing else. A case governed by a condition nobody stated would be handled confidently and wrongly if the system could not stop, which is why the stop is part of the architecture and not an enhancement. The legal position in this area is specific to each jurisdiction. It needs its own legal review, and every encoded rule has to be re-verified against current law before it is relied on. Ledgers from senders outside the handled set are out of scope.
Insurance claims, medical billing, expense reimbursement, regulatory filings and tax computation share this structure. A person signs a figure that a machine assembled, the source document records what happened, and a rule kept somewhere else decides what belongs in the figure. In each of them, derive the figure from its components, supply the conditions as inputs, store the derivation, and give the system a way to stop.
A document's stated total reflects its author's rules. When different rules govern what may be claimed, extract the components and derive the figure yourself.
Extraction accuracy measures output against the source document, which only matters if the source document is the thing you are trying to get right.
Conditions that decide a rule often live in another document. Make them explicit inputs so every exclusion traces back to something a person stated.
Store the derivation with every figure. A challenge answered with a trace is a lookup, and one answered without it is an argument.
Give any rule-based system whose output someone signs a way to stop. An abstention costs a review, and a confident wrong answer costs the person who signed.