How TieoutIQ ties out a brokerage statement
A tie-out agrees one set of figures against another prepared independently. Here the independent figure is the statement's own printed total. That check is the gate extraction has to pass, not a report printed after the fact.
The printed total is the reference
Every statement states what the account is worth. TieoutIQ finds that printed figure, sums the positions it extracted, and compares the two. A position set that lands within half a percent of the printed total is accepted. One that does not is not accepted, and does not quietly become a proposal.
Verification is the acceptance gate
This ordering is the whole design. Reconciliation does not run after the extraction has been handed to you; it decides whether the extraction is handed to you at all. A parse that cannot be tied out falls through to the next strategy instead of shipping.
Arithmetic, not judgement
The check itself involves no model. It is a sum compared against a printed number at a fixed tolerance, and the same tolerance is applied when the result is validated and recorded, so the figure on screen and the figure in the audit log are decided the same way.
The stages, in the order they run
Earlier stages are cheaper and more auditable, so they go first, and later stages only see what the earlier ones could not tie out.
Deterministic parse of the text layer
Most statements carry a real text layer. Rows are rebuilt from word coordinates, and a line is treated as a position only when some triple of its numbers satisfies quantity times price equals value. No model is involved at this stage at all.
Ledger reconstruction
Some documents are activity statements with no holdings table. Open positions are rebuilt by replaying the ledger, and the reconstruction has to reconcile against the printed ending equity. Values there are cost basis, because market prices are not in the document, and those rows carry reduced confidence so the review queue surfaces them.
Model extraction, same gate
What the algorithm could not read goes to a self-hosted two-stage pipeline: one pass to read the page, one to structure it. Its output is put through the same arithmetic reconciliation before it is accepted. Passing the gate is what counts, not which stage produced the rows.
Review queue, then a proposal
Each account arrives with a verdict of passed, needs review, or failed. Flagged rows are corrected in place and attested, verification runs again, and the correction is recorded. Only then can a proposal be generated.
Currencies are tied out before they are converted
A statement printed in euros is reconciled against its own euro totals. Converting first and reconciling afterwards would check a number the custodian never published, so it is done the other way round.
Each statement in its own currency
Verification happens per statement, against the totals that statement printed. Where a statement has subsections in another currency, the conversion uses the rates the statement itself printed.
You choose the reporting currency
Combining a household across currencies is a decision you make, not a default. Nothing is combined until a reporting currency is chosen.
The conversion is disclosed per row
A converted row keeps its original amount and the rate used beside the converted figure, and the period-end rate, its source and its date print on the page and on every export. TieoutIQ reads 18 currencies.
Common questions
What does tie-out mean here?
Tying out means agreeing one set of figures against another that was prepared independently. In TieoutIQ the independent figure is the statement's own printed total, so the positions we extracted are checked against the number the custodian published on the same page. If the two agree, the extraction is accepted. If they do not, it is not.
What tolerance counts as reconciled?
Half a percent. A position set whose sum lands within 0.5% of the statement's printed total is treated as reconciled, and the same tolerance is applied in the API's validation step so the number you see on screen and the number recorded in the audit log are decided the same way.
What happens when a statement does not reconcile?
Nothing is silently published. The account is marked as needing review or failed, every row is shown with the reconciliation figures beside it, and a proposal cannot be generated until each flagged row is corrected, confirmed, or overridden with a note. Corrections are written to the audit log with the original and the replacement.
Is a model deciding whether the numbers are right?
No. The reconciliation check is arithmetic: the extracted positions are summed and compared against a printed total. Models are used to read statements the deterministic parser could not read, and their output is put through the same arithmetic check before it is accepted.
Can our compliance team reproduce the check?
Yes, for extracted figures. Each one traces back to the statement row it came from, and each proposal itemises the corrections made during review. Computed figures such as fee drag and transition-tax estimates are derived from those positions rather than printed on the statement, so they trace to the inputs rather than to a row.