Technical product overview
TieOut rebuilds a client's bank and credit-card backlog into an import-safe cleanup package: extracted rows, cross-account reconciliation, source proof, books checks, and QuickBooks-ready exports in one workflow.
6 public-bank formats scored at summary level
synthetic eval rows used for regression pressure
hard gate for extraction tie-outs
hard gate for transfer and payout matching
Product system
TieOut is built around the accounting failure modes that appear only after conversion: internal transfers booked as income and expense, duplicated bank-feed overlap, processor payouts counted twice, missing statement periods, and rows that cannot be traced back to source evidence.
Other tools convert one statement into rows. TieOut owns the cleanup layer around conversion: every account, every month, processor exports, already-booked rows, review exceptions, and a final package that can be handed to a client or imported into QuickBooks.
The core rule is conservative: no quiet export when arithmetic, source evidence, coverage, or human confirmation is incomplete. The product turns uncertainty into a typed review state instead of letting it leak into the books.
Product workflow
TieOut follows the product path from imported statements to reviewed cross-account proposals to export, and blocks output until the ledger is safe to import. The visible screens are deliberately plain because the hard work is in the graph: accounts, periods, transaction rows, proposal status, evidence links, and export readiness.
Technical specs
The system separates per-document extraction from per-engagement reconciliation. That separation makes failures easier to reason about, test, and explain to a reviewer. A bad document extraction is handled as a statement problem; a bad transfer or duplicate relationship is handled as an engagement problem.
extractStatement(input) -> StatementObject
Per-document, stateless extraction that lands every bank or card statement on one typed object with account fields, summary totals, rows, source references, confidence, and tie-out status. The statement tie-out is the QA layer that keeps extraction errors from flowing forward.
fromStatementObject(so, ctx) -> CanonicalTxn[]
Decouples extraction from reconciliation, maps row-level flow semantics, stamps globally unique transaction IDs, and preserves source provenance for review. The adapter is what lets different statement lanes land on the same ledger contract.
reconcileEngagement(id, statements, opts) -> Engagement
Builds the engagement graph, runs deterministic passes for transfer matching, carry-forward continuity, deduplication, feed seams, and processor payouts. The engine proposes relationships, typed exceptions, and export readiness without mutating source rows.
buildExport(engagement) -> QuickBooks CSV | blockers
Exports only when no review-required exception remains and no match is still proposed. The system prefers blocked output over quiet accounting errors, then emits stable import rows and supporting evidence once the gate clears.
Equal amount within epsilon 0.005, date window up to 5 days, compatible flow roles, one-to-one greedy assignment by score.
Validates closing[m] == opening[m+1], flags coverage gaps and overlapping periods before export.
Groups by account, date, absolute amount, and normalized description; proposes dropping extras, never mutates silently.
Collapses processor payout report plus matching bank deposit into one settlement row to prevent double-counted revenue.
PDFs / markdown
-> Statement Engine
-> StatementObject[]
-> CanonicalTxn[]
-> Ledger Engine
-> Engagement { matches, exceptions, exportReady }
-> gated QuickBooks CSV
The key design choice is that matches are proposals, not hidden mutations. The UI and CSV exporter share the same readiness check, so a reviewer and an export job are looking at the same blocking state.
Evidence
The important signal is not just that the app runs. It is that the domain risks are named, modeled, tested, and kept out of export until they are resolved. TieOut treats bookkeeping cleanup as a verifiable workflow with typed data contracts and scorecards, not a loose PDF-to-spreadsheet utility.
TypeScript pnpm monorepo with separate web, API, engine, statement-engine, shared, and worker packages so extraction, reconciliation, storage, and UI can evolve independently.
Deterministic-first financial logic where arithmetic decides relationships and any OCR or model-assisted lane is bounded by confidence, provenance, and review states.
Explicit data contracts for StatementObject, CanonicalTxn, Match, LedgerException, Engagement, export rows, source references, and review decisions.
Eval-driven quality story with hard gates, scorecards, seeded synthetic corpus, real-substrate distractors, GL-diff strategy, and active-learning decision logs.
Product UX tied directly to engine constraints: source proof, proposal review, coverage checks, books checks, export blocking, and import-safe QuickBooks output.
Actual product surface
The real product is more than one reconciliation table. It includes client cleanup tracking, source-backed row repair, billing, and a support loop for statement formats that need coverage. These surfaces matter because firms need repeatable operations around the engine, not just a one-off conversion screen.
Client backlogs are tracked as cleanup workspaces with period scope, assignment, status, plan limits, and the queue context a firm needs to manage many catch-up jobs.
Statement rows stay source-backed, editable, and visible before anything is allowed into an export package, so review can happen at the row level instead of in a detached spreadsheet.
The commercial surface is page-metered and tied to cleanup limits, export packaging, and team workflow, matching the way bookkeeping firms think about statement volume.
Unsupported statement layouts become support requests and fixture-building opportunities, turning failed extractions into repeatable coverage improvements.
Control plane
Operational output
The final package is not just a CSV. It includes import-ready rows, account workbooks, review exceptions, source reference indexes, metadata, and a client-facing report so a bookkeeper can explain what changed, what was excluded, and why the result is safe to import.
Open TieOut app