Four documents, one spread, one cited cell.

A credit analyst opens a borrower packet and finds four documents that all claim to describe the same business in the same year. The company-prepared financial statement reports revenue for a fiscal year ending in June. The tax return reports it on a calendar year. The bank statements show deposits that include a shareholder loan nobody called revenue. The payroll records show a wage bill the income statement rounds into one line called operating expenses.

None of those documents is wrong. They were produced for different readers, on different calendars, under different rules. Spreading is the work of putting them into one shape a credit decision can use — and the interesting engineering is not the arithmetic. It is deciding which document is the source of each number, and being able to point at the line it came from a year later.

A spread is a normalization, not a transcription

The naive model of spreading is data entry: read the balance sheet, type the numbers into the template, repeat for the next borrower. That model survives because it is what the manual process looked like. It also explains why automating it often disappoints — a system that only copies numbers faster inherits every ambiguity the analyst was quietly resolving by hand.

A spread is a normalization. It takes values expressed in one document's vocabulary, period, and currency, and restates them in the vocabulary, period, and currency the credit template uses. That restatement is a series of small decisions, and each one can be right or wrong independently of whether the underlying value was read correctly.

• Extraction — the value on the page was read correctly, with a region on the source document behind it.
• Mapping — that value belongs in this line of the template rather than another one.
• Normalization — period, currency, sign convention, and units match the template's definition.
• Reconciliation — where two documents describe the same fact, the difference is explained rather than averaged away.

Systems that conflate these four report a single confidence number and leave the analyst unable to tell a misread digit from a debatable mapping. Those are different failures with different remedies, and only one of them is fixed by looking at the page again.

The four documents do not agree by default

The typical commercial packet has a financial statement, a tax return, bank statements, and payroll records. Each is authoritative about something, and none is authoritative about everything.

• The financial statement — the borrower's own presentation, on the borrower's fiscal calendar, prepared under the borrower's accounting policy.
• The tax return — filed under rules written for taxation, not for credit, with deductions and timing that serve a different purpose.
• The bank statements — the only document that records cash actually moving, and the one least willing to say what the movement was for.
• The payroll records — wage and headcount detail the income statement usually aggregates away.

The tension is structural. Depreciation on the tax return follows a schedule chosen for tax; the same asset on the financial statement may follow another. Revenue recognized when invoiced appears in the statement in one period and in the bank in a later one. A single owner draw can be a distribution on the statement, a wage on the payroll file, and an outbound transfer in the bank data.

Spreading them into one view means picking a source of truth per line and saying so. Financial spreading from documents describes the extraction side of that: borrower packets go in, normalized values come out, and every value keeps a reference back to the page it was read from.

Period alignment comes before arithmetic

The first thing to get right is the calendar, because every ratio downstream inherits it. A fiscal year ending 30 June and a calendar-year tax return do not describe the same twelve months, and quietly treating them as the same year produces a debt-service coverage figure built from two different periods.

Alignment is a rule, not a guess. State the template's period definition, derive each document's own period from the document, and record the transformation used to bridge them. When the bridge is not exact — a stub period, a change in fiscal year end, a return covering a short year after incorporation — that fact belongs in the spread, not in a footnote the model never reads.

The same discipline applies to currency and to sign convention. A spread that silently flips the sign of a contra account is arithmetically consistent and semantically wrong, and it will pass every balance check you run against it.

Every cell needs a source line

The property that makes a spread reviewable is that each cell can name where it came from. Not "the tax return" — the line of the tax return. US returns make this unusually tractable, because the form itself numbers its lines: tax return extraction returns a flat schema keyed by IRS line number, so agi_line_11 means the same thing whether the filer used software or paper.

That is the shape to aim for everywhere in the packet, even where the source document has no official numbering. A cell in the spread should carry the document it came from, the identifier of the line within that document, the region of the page behind it, and the transformation applied between the two.

• Source document — which file, which version of it, and which page.
• Source line — the form line number where one exists, or a stable identifier derived from the statement's own structure.
• Region — the area of the page a reviewer can open to see the value in place.
• Transformation — the period, currency, sign, or aggregation rule applied on the way in.

With those four present, a disagreement becomes a question an analyst can answer in a minute. Without them, the spread is a set of assertions whose provenance lives only in the memory of whoever built it.

Make one disagreement concrete

Take revenue for a calendar year. The financial statement reports 4,120,000. The tax return reports 3,940,000. The bank deposits total 4,305,000. Three documents, three numbers, one line in the template.

An averaging system produces 4,121,667 and a false sense of precision. A first-document-wins system produces 4,120,000 and hides the other two. What a credit analyst actually needs is the shape of the difference: the return excludes an amount recognized in the statement but not yet taxable in that period; the deposits include a 300,000 shareholder injection and a 115,000 refund that were never revenue.

Two of those three reconciling items are visible only in the transaction detail. That is where a categorized statement earns its place in the packet — not as the revenue source, but as the document that explains why the other two disagree. Classifying the lines inside a single statement is its own problem, covered in the statement is worth its lines, not its balance; here the categorized output is an input, and its job is to account for a gap rather than to fill a cell.

Adjustments are a decision, not a cleanup step

Most credit templates carry adjusted figures: EBITDA with owner compensation normalized, revenue net of non-recurring items, cash flow before discretionary distributions. These adjustments are judgments about what the business would look like under different ownership or in a normal year. They are also where a spread stops being a mechanical restatement.

Treat them as first-class and reversible. The unadjusted value, the adjustment, the reason, and who made it should all survive into the record, so a reviewer can disagree with one adjustment without rebuilding the spread. A system that writes only the adjusted number has destroyed the thing a second reader would want to inspect.

This is also the boundary where automation should stop and say so. A model can flag a payroll figure that looks like owner compensation and surface the payroll line supporting it. Deciding whether to add it back is a credit policy question, and it belongs to the institution, not to the extraction layer.

Confidence belongs to the cell

A packet-level confidence score is close to useless for review. The analyst does not need to know that the packet is 94 percent good; they need to know which three cells to look at. Confidence that is attached per value, and that a reviewer can sort by, turns a spread into a queue of decisions.

It also has to distinguish the two ways a cell can be uncertain. A low-confidence read means the system is unsure what the page says, and the remedy is to look at the region. A low-confidence mapping means the system is unsure where the value belongs, and the remedy is a rule or a human judgment. Collapsing both into one number sends every exception down the same path, and half of them will be the wrong path.

Validation helps at a third point: arithmetic internal to a document. Tax return line arithmetic can be checked against the form's own rules before the value ever reaches the template, so a transposition is caught at the source rather than as an unexplained variance four steps later. Catching it early is the same argument made in validate at capture time, applied to a form that publishes its own consistency rules.

What the spread does not decide

A normalized, cited, period-aligned spread is an input to underwriting. It is not underwriting. It does not decide whether the borrower is creditworthy, what the covenant package should be, or how to price the facility. Those are policy and judgment, exercised by people who are accountable for them.

Nor does the spread replace the packet. The documents remain the evidence, and the spread remains a view over them that a reviewer can walk back. A spread that cannot be walked back has converted evidence into assertion, which is precisely the conversion an audit later asks you to undo.

It is worth naming a related shape that is not this one. Turning one document family into a structured operating record — a lease into critical dates, rent steps, and options — is abstraction, and its hard part is completeness within a document. Spreading's hard part is agreement across documents that were never written to agree.

Before you wire a packet into underwriting

If you are evaluating whether to automate spreading, the questions that separate a useful system from a fast typist are narrow ones.

• Per-cell provenance — can a reviewer open the source line and region behind any value in the spread?
• Explicit period rules — does the system state each document's period and the transformation used to align it?
• Separated confidence — does it distinguish an uncertain read from an uncertain mapping?
• Reversible adjustments — do the unadjusted value, the adjustment, and its reason all survive into the record?
• Reconciliation output — when two documents disagree, does the system produce the reconciling items or only a winner?
• Downstream payload — does the JSON handed to the loan origination system carry the citations, or only the numbers?

The last one decides whether the audit trail survives the integration. A spread with full provenance that flattens into bare values at the API boundary has an audit trail that ends where the decision begins.

Four documents, one defensible view

Spreading looks like transcription and behaves like reconciliation. The four documents in a borrower packet were produced for four different readers, and the work is to state — per line, on the record — which one answers the template's question and why the others differ. Extraction makes that work faster. Citation is what makes it reviewable.

Build the spread so each cell names its source line, each alignment names its rule, and each adjustment names its author. The credit decision on top of it is still a human judgment, but it becomes a judgment someone can reconstruct.