Every financial document pipeline that reaches production has a review queue in front of the database. Somewhere between the extraction API and the system of record, a person looks at the statement of condition, the income statement, or the capital account schedule and decides whether the numbers can be trusted. Teams we talk to have built that queue themselves, and the ones who have built it well tend to arrive at the same design. This post describes that design, explains why the extraction output has to be shaped for it from the start, and shows what it looks like against a real set of audited financial statements.
Why the queue exists at all
Financial statements carry their meaning in hierarchy. A balance sheet is not a list of line items; it is a tree in which "Total assets" is the sum of indented children, in which a parenthesized figure is a contra balance rather than a negative, and in which a note reference attached to "Loans" points to three pages of disclosure that change how the figure should be read. Extraction systems that flatten that tree produce numbers that look right and reconcile wrong.
Even with structure preserved, a model will occasionally be uncertain. A smudged scan, a column that wraps onto a second page, a statement in which the current and prior year columns are swapped relative to last year's filing: these are the cases where an analyst's eye still matters. The review queue is where that attention is applied, and the question is how to make sure it lands on the five fields that need it rather than the five hundred that do not.
The anatomy of a review queue that works
The pattern that mature teams converge on has four components, and customers have described building nearly identical versions of it independently.
The first is a split view, with the source page rendered on one side and the extracted fields on the other, broken down by document section rather than presented as one long form. The balance sheet fields sit under a balance sheet heading, the income statement under its own, and the notes under theirs, so a reviewer can work the document the way they would read it.
The second is section-level status. Each section carries an indicator showing whether it has been reviewed or is still pending, and the reviewer can save inline edits as they go. Work persists until the reviewer submits the document for a final quality check, which is the gate before anything flows to the downstream database.
The third is typed fields rather than text. A reporting date arrives as a date, which means the interface can show a date picker rather than a free text box. A statement type or a currency unit arrives as a categorical value with a known set of options, which means a dropdown. A schedule of investments arrives as repeatable rows, each with its own sub-fields, so a reviewer can correct one holding without disturbing the others. The extraction schema is what makes this possible, and it is why Pulse's schema-driven extraction supports dates, enumerations, nested objects, and arrays as first-class types rather than coercing everything to strings.
The fourth component is the one most teams add last and wish they had added first: confidence-driven ordering.
Confidence is what makes review scale
Customers have told us that their first version of the queue showed every extracted value flat, with the same visual weight, and that reviewers responded by checking all of them. That is the rational thing to do when the interface gives no signal about where the risk is, and it is also the reason the queue becomes the bottleneck. Review time scales with field count rather than with error count.
The fix is to surface low-confidence fields first. Pulse returns a calibrated confidence score with every field and every table cell, calibrated in the sense that a score of 0.9 corresponds to roughly ninety percent accuracy on documents of that kind in production, rather than being an uncalibrated softmax value. With that signal in the output, the queue can sort fields by confidence, highlight the ones below a threshold, and let a reviewer accept the rest in bulk with the bounding box as the audit trail. A click on any field jumps to its location on the source page.
The threshold is not a constant. Teams running this in production report that accuracy begins to fall off somewhere in the high eighties for their document mix, but the exact point depends on the statements, the scan quality, and the schema. It has to be calibrated against real usage over a few cycles, which is a reason to capture reviewer corrections as data from the beginning. Each correction tells the pipeline where the model was overconfident, and each accepted field above the threshold tells it where the threshold could move.
What the statements themselves demand
The audited statements of a large financial institution are a useful stress test for this design, because they contain nearly every structure that breaks extraction. The statements of condition present assets and liabilities in a two-year layout with deep indentation, parenthesized contra balances, and subtotal rows that are bold rather than labeled. The notes add merged header cells spanning several columns, footnote markers attached to individual numbers, and tables that continue across page breaks with their headers repeated.
Pulse returns each of these as a table object with cell-level position, text, confidence, and geometry, with spanned tables merged across pages and footnotes linked to the cells that reference them. The queue can therefore show the balance sheet as a grid in which every cell is individually addressable, which is what lets a reviewer correct one number without re-keying the row.
What the queue is built on
The image below shows a page from the notes to a publicly available set of audited financial statements, with the original on the left and the Pulse extraction on the right. The page carries two schedules and the prose between them: a securities holdings table with a two-level header that nests par value, unamortized premiums, unaccreted discounts, and total amortized cost under each of two years, and a repurchase agreement schedule beneath it. Every value in both tables is located inside the table boundaries the API returned, the merged header cells are preserved as headers in the structured output, the paragraphs between the tables come back as text blocks, and every box drawn on the page comes directly from the API response. This is the raw material the review queue is built on: not a block of text that resembles a financial statement, but a grid of addressable, confidence-scored cells that a reviewer can trust, correct, and sign off on.
Extraction is not finished when the API returns. It is finished when a person has looked at the right fields and signed off. Building the output for that moment is what turns a document pipeline into financial data.
