Method

Every check, by name

Every check by name, in plain words. Method v1.0, 2026-09-11. The version is printed on the cover of every exhibit; the same files, the same version and the same edits produce the same findings hash.

Proof

Balance identity: Printed opening balance plus every credit minus every debit must equal the printed closing balance, to the cent. On a card statement: previous balance plus charges minus payments and credits equals the new balance.
Running-balance chain: Where the statement prints a balance per line, each printed balance must equal the previous one plus the line. The first row where it does not is shown with the difference.
Month chain per account: The closing balance of one statement must be the opening balance of the next statement of the same account. A day missing between two statements is a gap; a day shared is an overlap; a balance that does not carry over is a break. Each is listed with the two exhibit numbers.
Read in part: When some pages could not be read, the rows read are still proven against the printed balances and the entry says which pages were not read.

Trace

Transfer matching: A debit in one account and a credit in another account of the matter, equal in amount and within a short window of banking days, are paired one to one. Transfer wording and a cited account number rank rival candidates. Both citations are printed.
Unmatched outflows: Debits with transfer or wire wording, or naming another account of the matter, for which no credit of the same amount was found in any account of the matter.
Counterparty totals: Descriptions reduced to a payee label, grouped per statement, largest first, with a sample of the raw description so the grouping can be judged.
Ledger comparison: A QuickBooks, Xero or plain-sheet export is matched line by line with the bank rows of the account it names, within its own date range: bank lines with no ledger entry, ledger entries with no bank line, both cited.
Payment-app links: A transfer to or from the bank in a PayPal, Venmo or Cash App export is linked with a bank row of the matter: the amount the bank sees (net of the app's fee on a payout), the same direction, within a short window; an account number named in the export ranks rival candidates. Payouts with no bank line, and bank lines that name the app with no line in the export, are listed. The app's person-to-person lines are grouped by the name or handle as the app printed it, with the app's transaction ids as citations.

Structure of the file

File identity: SHA-256 of the bytes as received, size, page count, PDF version, producer and creator, creation and modification dates, end-of-file markers and incremental saves, fonts, encryption state, text layer per page, image pages with their pixel dimensions, presence of a signature dictionary.
Producer and creator class: The software that wrote the file is classified and weighed. A re-saved file is reported as provenance not assessable, never as altered.
Modified after creation: A modification date later than the creation date means some tool re-saved the file after it was written.
Incremental saves: The footprint of a file edited in place after it was written; signing a file leaves the same footprint and is reported as such.
Template fingerprint: The production stack of the file is compared with known specimens of that layout where they exist.
Mixed production stacks: Statements claiming the same bank produced by different software stacks.
Months created on one day: Statements for several months that were all written on the same day. Weighed with the rest, never alone.

Typography of the page

Earlier revision inside the file: Where a file carries an earlier version of itself, the two are compared; replaced or added text is weighted high, removed text (a redaction) is a review note.
Row typography: Every transaction row on a page is set the same way. A row set differently from the rest of the page is listed with its text. Bold total rows and footnote marks are not odd.
White-out over text: Marks painted over text already on the page, covering it.
Text over text: Two different texts occupying one line of the statement.
Text layer against the print: A digital page carries every figure twice: in the text layer that copy, search and any parser read, and in the glyphs the page draws. Both are compared, figure by figure, using the same OCR engine on a picture of the page. Where they differ the cell is read again on its own, twice, and only a difference all three readings agree on is listed. Money and dates are compared; a page whose print the engine cannot read as figures is reported as not measured rather than guessed at.
Row geometry on scans: On a scanned page, word baselines, letter heights and row edges are measured from the OCR word boxes; words that sit off their row are listed. Thresholds come from the scan's own noise and were set on real scanned statements so that clean pages produce no note; the entry says which pages were measured and which had too few rows to test.

Content of the rows

Duplicated lines: Identical credit lines on the same day whose printed balances cannot confirm them as separate transactions.
Repeated identical deposits: The same deposit description and amount recurring across days.
Summary box against the ledger: Where a statement prints deposit and withdrawal totals, they must equal the rows; tested only when the rows already tie, so a misread row can never produce this note.
ACH on a non-banking day: A line labelled ACH posted on a weekend or a US federal holiday.

Reading

Text layer first, OCR second: A PDF with a text layer is read from the text layer. Only when that read does not tie, or there is no text, are image pages read by OCR on our own server, in memory, and the OCR read is kept only when it is the one that ties. OCR-read rows are marked.
Never a refusal: Every file dropped into a matter gets a register entry: read, read in part, or examined but not read, with the reason in plain words and the list of checks that could not run on it.

Weights

Every note is a review signal. A note is weighted high only where the checks have shown, on real files, that no ordinary explanation remains; everything else is marked review. A new check ships at review weight and earns a higher weight only after real matters show where the line sits.

What is not checked

Docuritas proves the numbers and flags what broke a check. What stays with the examiner:

Whether a statement is altered. The exhibit reports what the arithmetic, the calendar and the file itself show, and what to ask the bank for. Reading those facts into a finding is the examiner's work.
Provenance of a printed-and-rescanned statement. A rescan carries none, the register says so, and the proof rests on the arithmetic and the month chain instead.
Visual inspection. Logos, layout and image content are not compared to a genuine specimen; the method reads the file's own structure, fonts and row geometry, not how the page looks to the eye.
Identity and screening of any party, and the purpose of a transfer. Counterparty labels are grouped from the printed description; what they mean is the examiner's call.
The opinion. The exhibit is a mechanical record with a hash. The report that rests on it, and its conclusions, are signed by the examiner.

Reproduce an exhibit

A procedure an opposing expert can follow and a sponsoring witness can testify to having followed. Two hashes are involved and they claim different things. The findings hash, printed on the cover and in the footer of every page, is computed over the input file hashes and their declared sources, every row as exported, the method version and the reviewer's screen parameters — never the matter name, the reviewer or a file's name; it is the same on any computer. The file hash is SHA-256 of the exhibit PDF itself; it is the same only on the same software build, with the same preparation date (printed in UTC) and in the same form (the exhibit for filing, or the working paper), all three of which are printed on the cover — the preparation date is deliberately outside the findings hash, so a rerun on a later date reproduces every figure without pretending it was prepared that day.

Take the exhibit PDF as delivered. Note the method version, the engine line and the findings hash on the cover.
Run shasum -a 256 exhibit.pdf and compare with the file hash shown on screen when the exhibit was downloaded. A match proves the file is the one produced.
Assemble the same source files, in the same order, with the same declared sources. The register lists each file's SHA-256 as received; check them first.
Re-run the matter with the same method version, the same hand edits (section 10 of the exhibit lists them) and the same screen parameters (printed in section 4).
Compare the new findings hash with the original. A match proves every number in the exhibit is reproduced. On the same software build, with the same preparation date and in the same form, the new PDF's SHA-256 matches too, byte for byte.

Where a page was read by OCR, the OCR engine and its training data are part of the findings hash, because a different reader of an image is a different engine. Reruns pinned to a prior method version are available on request. There is no lookup service for hashes and there never will be: confirming a hash would mean keeping a record that the matter existed, and nothing is kept.

Why no model sits in the arithmetic path

Not a position on a technology; a specific failure mode. A language model produces plausible continuations, and a reconciled statement is more plausible than an unreconciled one. On statements that tie cleanly it performs well, and those are the ones nobody needed checked. On the statement whose closing balance is off by 4,200.00, its bias is to smooth the discrepancy into something that reconciles, confidently and silently. The error concentrates on exactly the cases this method exists to find, and no prompt or second model fixes that. Try it on the synthetic sample, never on a client's file: ask any assistant to verify the opening and closing balances and compare with the exhibit.

The rule that follows: a model may propose, only arithmetic may dispose. Nothing that computes, adjusts, infers or reconciles a number in the exhibit, the register, the proof or the findings hash may come from a model. Today nothing in the pipeline uses one at all.

Version log

The version is printed on the cover of every exhibit. A check added, removed or re-weighted is listed here with its date, so an exhibit can be read against the method that produced it.

v1.0 · 2026-09-11: First public version. Every check by name is on this page: balance identity, running-balance chain, month chain per account, transfer matching, file identity, producer class, duplicated lines, ACH calendar, row typography and row geometry on scans, and the text layer of a digital page compared with what the page prints, figure by figure. Scanned pages are straightened, their table rules removed and read with the larger OCR model; a scan read only in part is reported as read in part, never as reconciled. A figure the text layer cannot express is taken from the printed page only when two separate reads of it agree, and the row says so. Calibrated on real bank and card statements, digital and scanned, to produce no note on a clean file.

Benchmark

The engine is scored on a labelled corpus of altered and genuine statement sets, kept as the regression suite that gates every release. Cases the method does not resolve are listed in the exhibit as not checked.