A Sensible Alternative
Pre-Trained Financial Extraction Without Writing a Config
Sensible is a developer platform for document extraction: you describe a document type in a config — queries, anchors, LLM prompts — and its API returns the fields you defined. FlowParse is the finished layer for financial documents: pre-trained on statements, invoices and receipts, so there is no config to author, with balance validation, Smart Merge and native QBO/QFX/OFX/Xero export, as a self-serve app and an API.
Developers extracting bespoke or long-tail document types who want explicit, versioned control over exactly how each field is found — and are happy to author and maintain a config per document type.
Teams whose documents are financial and who want validated, importable data immediately — with no config to write, no layout to onboard, and accounting export already built.
Why Businesses Look for Sensible Alternatives
Nothing to configure
Statements, invoices and receipts are pre-trained. A bank you have never seen works on the first upload.
Balance validation in the box
A deterministic check confirms opening + transactions = closing, with a 0-100 quality score — no rules to author.
Accounting-ready export
Native .QBO/.QFX/.OFX and Xero/Excel files, not fields you map into a ledger yourself.
An app, not only an API
Non-developers convert and review a statement in the browser — no code, no config.
Consolidation built in
Smart Merge turns a year of PDFs into one reconciled Excel — a workflow, not an extraction.
Self-serve and free to start
Run a real statement through the whole flow today, with a free monthly allowance.
Quick Comparison — Sensible vs ParseFlow
A feature-by-feature look at Sensible and ParseFlow AI.
| Feature | Sensible | ParseFlow AI |
|---|---|---|
| Bank statement PDF → structured transactions | Author a config first | Yes |
| Works on an unseen bank layout with no setup | Config may need extending | Yes |
| Debit/credit → single signed amount | Define it yourself | Yes |
| Balance reconciliation + quality score | No | Yes |
| Native .QBO / .QFX / .OFX export | No | Yes |
| Xero / Excel / CSV export | Build it yourself | Yes |
| Smart Merge — 100 PDFs → 1 Excel | No | Yes |
| Self-serve app for non-developers | No | Yes |
| Editable review grid for humans | Build it yourself | Yes |
| Arbitrary / bespoke document types | Yes | Financial set only |
| Explicit per-field control | Yes | Pre-trained, review + correct |
| REST API | Yes | Yes |
What Is Sensible?
Sensible is a document-extraction platform aimed squarely at developers. Rather than shipping one opaque model, it has you describe the document: you write a configuration that says how to find each field — anchors and spatial queries for structured layouts, LLM-backed prompts for the parts that resist rules — and its API returns exactly the schema you defined, with a playground and version control around the configs. For teams pulling data out of documents that no off-the-shelf model understands, that explicitness is genuinely valuable: when a field comes back wrong, you know where to look, and you can fix it deterministically rather than hoping a model improves.
What Sensible asks in return is authorship. Somebody has to write the config for each document type, and then keep it working as layouts drift. For a handful of stable, structured document types that is a fair trade. For bank statements it is a harder one, because there is no such thing as "the bank statement layout" — there are thousands, they change without notice, and the long tail is where the work actually is. And what comes back is still the fields you asked for: reconstructing a full transaction list, normalising debits and credits into signed amounts, checking that the balance reconciles, and producing a file an accounting package will import are all downstream of the extraction, in your product.
FlowParse takes the opposite position for the financial case. It is pre-trained on bank statements, invoices and receipts, so there is no config to author and no layout to onboard — a bank nobody has seen before is read on the first upload, because extraction is by meaning rather than by anchor. And the layers past extraction are already there: [validation](/features/validation-engine), the [editable review grid](/features/editable-preview), [Smart Merge](/merge-pdf-to-excel) consolidation and native [accounting export](/features/accounting-software-export). It is also an app as well as an API, so an accountant can convert a statement without a developer being involved at all.
Sensible strengths
- Explicit, deterministic control over how every field is found
- Handles bespoke and long-tail document types no prebuilt model covers
- Configs are versionable, testable and debuggable like code
- Developer-focused platform with a playground and clean API
Where teams want something different
- You author and maintain a config per document type — thousands of bank layouts is the wrong shape for that
- Returns the fields you defined — no balance validation, reconciliation or consolidation
- No native QBO/QFX/OFX/Xero export — you build the mapping
- API and platform for developers — no self-serve app for an accountant
Why Teams Switch to ParseFlow
Delete the config backlog
Pre-trained financial extraction means an unseen bank layout needs no work at all — not a new config.
Get the workflow, not just fields
Validation, review, consolidation and export come built in rather than assembled around an extraction.
Statements to a real bank feed
Export .QBO/.QFX/.OFX (OFX 1.0.2, FITID de-dup) so imports never double-post — no mapping to build.
A quality gate you can trust
Balance reconciliation, duplicate detection and a 0-100 score ship in the box.
An app for the non-developers
Accountants and ops staff convert and review in the browser, no code required.
Free to evaluate
Run a real statement through the whole flow before committing anything.
Authored config vs pre-trained engine
Sensible has you describe each document type, precisely. FlowParse already knows the financial ones.
Sensible path
- Write a config per document type
- Extend it for each new layout
- Handle returned fields in code
- Build validation + reconciliation
- Build export + a review UI yourself
FlowParse path
- Upload, or make one API call
- Any bank layout, no config
- Validated, signed transactions
- Balance check + editable review built in
- Export native QBO/QFX/OFX/Xero/Excel
Pricing Comparison
How the cost and commitment models compare.
| Feature | Sensible | ParseFlow AI |
|---|---|---|
| Free tier | Free tier available | Free pages/month + no-signup try |
| Model | Per document/extraction | Per page from a balance |
| Setup cost | Config authoring per doc type | None (pre-trained) |
| Self-serve app | No (developer platform) | Yes (browser app) |
| Accounting-export files | Build it yourself | Yes (QBO/QFX/OFX/Xero) |
| Setup to first result | Write a config | None (app) / one call (API) |
Accuracy Comparison
Both platforms use modern AI OCR — here is how extraction quality is assured.
| Feature | Sensible | ParseFlow AI |
|---|---|---|
| Structured, stable layouts | Excellent (explicit anchors) | Strong (out of box) |
| Unseen bank layout | Needs config work | Works immediately |
| Bank statement transactions | The fields you defined | Every row, balance-validated |
| Debit/credit normalisation | Define it yourself | Single signed amount |
| Balance reconciliation | No | Built in |
| Human review step | Build it yourself | Editable grid + API |
Who should choose Sensible?
- Developers extracting bespoke or long-tail document types
- Teams that want deterministic, debuggable control per field
- Products where document types are few, stable and well known
- Engineering teams happy to own and maintain configs
Who should choose ParseFlow?
- Accountants and finance teams converting statements and invoices
- Developers wanting validated financial data plus export from one call
- Teams facing many bank layouts they cannot possibly configure
- Anyone wanting a free, self-serve way to convert a document today
Migrating from Sensible to ParseFlow
Switching takes minutes — there are no templates to rebuild or models to retrain.
Export your documents
Export invoices and statements from Sensible or your source.
Upload to ParseFlow
Drag and drop PDFs, scans, or images — no setup.
Review extracted data
Check fields in the editable preview before export.
Export Excel or CSV
Download structured data for your accounting system.
Automate workflows
Use the API and integrations for future documents.
Sensible vs FlowParse: authored control vs pre-trained coverage
Both turn documents into data, but they start from opposite convictions about who should know the document. Sensible believes you should. You write a config that describes where each field lives — anchors, spatial relationships, table queries, an LLM prompt where rules run out — and the API returns precisely the schema you specified. The appeal is real: extraction stops being a black box. When something comes back wrong you know which line of config is responsible, you can test it, version it, and fix it deterministically. For a document type that no general model has ever seen, that is often the only approach that actually works.
FlowParse believes that for financial documents, the engine should already know. It is pre-trained on bank statements, invoices and receipts, and it reads them by meaning rather than by position — so a bank whose statement nobody has ever processed is read correctly on the first upload, with nothing to author. On top of that sit the layers a config-driven platform leaves to you: balance validation, an editable review grid, Smart Merge and native accounting export.
So the deciding question is the shape of your document estate. A few stable, bespoke document types that you understand deeply and nobody else supports? Authored configs are a strength, and Sensible is built for exactly that. Thousands of financial layouts you did not design, cannot predict and will never finish enumerating? Authorship is the wrong economics, and a pre-trained engine is the closer match.
The long tail is the whole problem
Configuring extraction for bank statements sounds tractable until you count the layouts. Every bank has one. Most have several — a current account looks nothing like a savings account, business differs from personal, and the credit card is different again. Then there are the app-based banks, the regional banks, the foreign accounts your customer has, the statement from 2019 that predates the redesign, and the scan of a posted statement that no anchor-based rule was written with in mind.
This is why config economics invert on financial documents. The first ten layouts are quick and satisfying. The next hundred are a backlog. The long tail — the one-off bank a single customer uses — never gets done at all, which means the honest answer to that customer is that their bank is not supported. That is a product limitation created by the extraction approach, not by the difficulty of the document.
FlowParse is pre-trained precisely so the tail costs nothing. Extraction reads the semantics of a statement — this column is a date, this is a description that wraps across two lines, these are debits, this is a running balance — rather than the coordinates of a particular bank's design. A layout nobody anticipated behaves like one that was: it just reads. There is no supported-banks list to maintain because there is no per-bank work to do.
The layers past extraction
Even a perfectly authored config gives you fields, and there is a surprising distance between fields and data your books can use. On a statement: the transaction list has to be reconstructed across page breaks, separate debit and credit columns merged into one signed value, day-first and month-first dates disambiguated, and — the one that actually matters — the whole thing checked to confirm that opening balance plus every transaction equals the closing balance the bank printed. Then a human needs somewhere to review the uncertain rows, and the result needs to leave as a file the accounting software will import.
On Sensible, each of those is yours to build and maintain in your product. FlowParse ships them: the same engine that extracts also normalises, validates and scores, offers the editable grid for review, consolidates a year of statements, and writes the accounting files — with scans handled through the same bank statement OCR API.
| Layer | Sensible | FlowParse |
|---|---|---|
| Field extraction | Yes (you author the config) | Yes (pre-trained) |
| New bank layout | Config work | Nothing to do |
| Transaction reconstruction | Build it yourself | Built in |
| Balance validation + score | None | Built in |
| Consolidate many statements | Build it yourself | Smart Merge |
| .QBO/.QFX/.OFX/Xero files | Build it yourself | Native |
The check a config cannot perform
There is one thing an extraction platform structurally cannot tell you, however good the config: whether the extraction is complete. A config finds the fields it was told to find. If a row was dropped at a page break, or a layout quirk hid three transactions, the response still looks perfectly well-formed — the fields are all there, the types are right, the confidence is high. Nothing about the output announces that money is missing.
FlowParse checks the statement against itself. Opening balance, plus every transaction extracted, must equal the closing balance the bank printed. If it does not, something was missed, and you learn it immediately rather than when a reconciliation refuses to tie out months later. That is the only check that can prove an extraction wrong with no labelled data and no human in the loop, and it is why validation is the feature rather than a footnote.
It matters most in exactly the situation config authorship is weakest: the unfamiliar layout. A statement you have never seen is where a dropped row is most likely and least noticeable — and where an arithmetic proof, rather than a confidence number, is what you actually want.
The accounting export gap
An extraction platform returns fields; turning them into a file your accounting software imports is your integration to build and keep working. FlowParse produces real Open Financial Exchange files out of the box: `.QBO` and `.QFX` for QuickBooks and Quicken, `.OFX` for tools like GnuCash and Sage, plus a Xero-ready CSV and clean Excel. Each transaction carries a stable `FITID`, which is what stops a re-import double-posting rows the user already has.
That is engineering you neither have to write on top of a config nor keep working as formats evolve. The accounting export feature and the PDF to QBO page list the formats and the exact import steps into each tool.
An app for the people who aren't developers
Sensible is a developer platform, and configs are code — which is exactly right when a developer is the user, and a wall when the person who needs the data is an accountant. They cannot author a config or call an endpoint; someone has to build for them first.
FlowParse is both. A non-developer opens the bank statement to Excel tool, uploads, reviews and exports — no code, no config — while a developer automates the identical capability over REST, billed per page. The bank statement API and document extraction API cover the programmatic path, with the parsing guide walking through the pattern.
One engine for statements, invoices and receipts
Choosing a finance-focused tool does not narrow you to one document. FlowParse extracts bank statements, invoices and receipts with full line items, supplier and buyer details, totals and a tax breakdown, and runs an AI VAT auditor on invoices — all on the same pre-trained engine, in a consistent schema.
Because everything comes back in the same shape, cross-document workflows are built in rather than assembled: an invoice you extracted can be reconciled against the bank payment you extracted from a statement, with no mapping between separate configs. On a config-driven platform, the invoice config and the statement config know nothing about each other, and joining them is logic you write.
Where Sensible's strength is that it can be taught any document, FlowParse's is that the financial set is already solved, validated and tied together — and usable without writing anything.
Where Sensible genuinely wins
A fair comparison names where the other tool is simply better, and for Sensible that is control and reach. If your document type is bespoke — a niche insurance form, a lab report, a contract annex, an industry document that exists in four companies — no pre-trained financial engine will help you, and Sensible's approach is the right one: describe it precisely, get exactly the schema you asked for, version it like any other code. FlowParse cannot do that, because it is deliberately pre-trained for the financial set rather than teachable.
The control is a genuine engineering advantage too. When an authored extraction is wrong, the cause is inspectable and the fix is deterministic — you change a config, you test it, you ship it, and it stays fixed. That is a debugging story a pre-trained model cannot fully match, and for teams who need to guarantee behaviour on a specific document, it is decisive. Configs also encode institutional knowledge in a reviewable artefact, which some regulated teams strongly prefer.
So the honest division is by document estate, not by quality. Bespoke, stable, few, and yours to understand? Sensible. Financial, numerous, unpredictable, and someone else's design? FlowParse. Plenty of teams run both — a configurable platform for the strange documents their business happens to involve, and a specialist for the financial backbone where validation and accounting export are the point.
Total cost of ownership, not just per-extraction price
Comparing on the meter alone hides where the money actually goes. With a config-driven platform, the extraction price is one line item; the real cost is the engineering to author configs, extend them for each new layout, notice when one silently breaks, and build the validation, consolidation, review UI and accounting export around them. On financial documents that is not a one-off project — it is a permanent backlog fed by other companies redesigning their statements on their own schedule.
FlowParse's total cost of ownership sits close to its per-page price because the engine is pre-trained and the workflow is finished. A new bank format costs nothing; validation, consolidation and accounting export ship in the box; and non-developers use it without any UI work from you. See the pricing page for plans — usage is visible per API key, so cost is predictable and attributable.
This is the build-versus-buy decision in its clearest form. If you want authored control over bespoke documents, Sensible earns its keep and FlowParse is not a substitute. If your documents are financial, paying to author and maintain configs — and then to build validation and export on top — means paying to recreate what a finance-specific engine already includes, app and all.
