The OCR decision every AP platform eventually faces
An accounts payable automation platform lives or dies on one unglamorous step: turning a supplier's PDF invoice into rows your product can actually work with. Everything else — approval routing, PO matching, payment scheduling, audit trail — depends on that first extraction being reliable. Most teams start by wiring up a general-purpose document AI service, then discover that "call an OCR API" and "have a working invoice extraction pipeline" are two very different amounts of engineering work.
This page describes the second option directly: an API purpose-built for invoices, returning an already-typed schema — header fields, line items, totals, confidence scores — instead of a raw OCR response you still have to parse into something your product can use.
Why the in-house version stalls
A general OCR API returns text and coordinates, not invoice fields
Textract, Document AI and Form Recognizer are excellent at reading pixels — turning that into supplier_name, invoice_number, line_items with correct quantities and unit prices is a separate parsing layer your team has to write and maintain.
Line-item tables are the hard 20% that takes 80% of the effort
Header fields are relatively easy. Correctly rebuilding a multi-page line-item table — with wrapped descriptions, sub-totals, and inconsistent column layouts across suppliers — is where most in-house extraction projects stall for months.
New supplier layouts keep arriving after launch
A rules-based or template-driven parser that worked at launch degrades as new suppliers send invoices in formats nobody anticipated, and every regression means an engineer, not a support ticket.
Confidence scoring is easy to skip and expensive to skip
Without a reliable per-field confidence signal, a team either reviews everything manually (slow) or trusts everything automatically (wrong data reaching the ledger) — building that scoring layer well is its own project.
None of this means building your own extraction layer is a bad idea in every case — a platform with a narrow, highly standardized supplier base and deep OCR expertise on staff can make it work. It means the honest cost of "build" is usually a multi-quarter project with ongoing maintenance, not a weekend spent wiring up an API.
What this API doesn't decide
Doesn't run approvals or workflow routing
It returns structured invoice data. Who approves what, at what threshold, and in what sequence, is entirely your product's logic.
Doesn't match invoices to purchase orders
PO matching depends on records only your platform holds. Extraction hands you clean invoice data to match against them — it doesn't hold your PO data itself.
Doesn't decide your confidence threshold
Every field carries a confidence score. Where you draw the line between auto-post and human review is a product decision specific to your users' risk tolerance.
Doesn't schedule or execute payments
Extraction stops at structured data ready for your ledger. Payment execution, whether via ACH, card or check, stays entirely outside this API's scope.
Where this sits next to Textract, Document AI and a full AP suite
Three different categories of product get compared in this decision, and confusing them leads to the wrong evaluation. A general-purpose document AI service (Textract, Document AI, Azure Form Recognizer) is infrastructure — you build the invoice-specific logic on top of it yourself. A full AP suite (the Bills/Rillions/Precoros of the world) is a complete product — approvals, PO matching, payment execution and all — that you'd be competing with, not embedding, if you're building your own AP platform.
This API sits between the two: purpose-built for invoice extraction specifically, so you get an invoice-typed response instead of raw OCR output, but it stops exactly where your product's own logic — approvals, matching, payment — begins. It's the layer you'd otherwise spend months building on top of a general OCR service, available as one API call instead.
The calls that matter
Four endpoints cover the entire extraction workflow. All of them are documented in full, with every parameter, on the API docs page— the versions below are the shape you'll actually call from an AP platform's ingestion pipeline.
curl -X POST https://flowparse.io/api/v1/extract \
-H "Authorization: Bearer pf_live_xxx" \
-H "Content-Type: application/json" \
-d '{ "file": "JVBERi0xLjcK...", "filename": "acme-invoice-1024.pdf" }'
# → { "type":"invoice", "pages":2, "billedPages":2,
# "price": { "eur":0.07, "perPageEur":0.035, "complexity":"standard" },
# "data": { "type":"invoice", "data": {
# "supplier_name":"Acme Supply Co", "invoice_number":"INV-1024",
# "invoice_date":"2026-05-01", "due_date":"2026-05-31", "currency":"USD",
# "subtotal":1840.00, "tax_amount":147.20, "total":1987.20,
# "line_items":[ { "description":"Widget, 10mm", "quantity":40,
# "unit_price":46.00, "tax_rate":8, "amount":1840.00 } ] } } }curl -X POST https://flowparse.io/api/v1/validate \
-H "Authorization: Bearer pf_live_xxx" \
-H "Content-Type: application/json" \
-d '{ "type": "invoice", "data": { "supplier_name": "Acme Supply Co",
"invoice_number": "INV-1024", "total": 1987.20, "currency": "USD" } }'
# → { "valid": true, "issues": [] }/validate is free regardless of plan, which makes it the right place to prototype your data contract before spending anything on extraction volume. /reconcile and /merge extend the same data model for matching invoices to bank payments and combining several documents — both documented on the API docs page, useful if your platform also needs payment confirmation or bulk processing.
What gets read from a supplier invoice
| Field group | Includes |
|---|---|
| Header | Supplier name, invoice number, invoice date, due date, currency, PO reference if printed |
| Totals | Subtotal, tax amount, total, typed as decimal numbers, not localized strings |
| Line items | Description, quantity, unit price, tax rate and line amount, for every row on every page |
| Quality signal | A confidence score per field, plus an overall extraction quality score |
A multi-page invoice with a line-item table spanning several pages is read as one continuous table — line items aren't split or duplicated at page boundaries, which is one of the more common failure modes in a hand-built extraction pipeline.
How pricing works
Extraction is billed at a flat rate per page — €0.035, the same whatever a document takes to process, no complexity multiplier to estimate. There's no per-seat licensing and no minimum monthly commitment to start.
curl https://flowparse.io/api/v1/usage \
-H "Authorization: Bearer pf_live_xxx"
# → { "plan":"PRO", "pricePerPageEur":0.035,
# "balance": { "pages":812, "monthlyRemaining":712, "bonusPages":100 },
# "thisMonth": { "requests":143, "pages":288, "spendEur":8.18 } }For an AP platform, this maps naturally onto your own pricing — the cost of extracting one supplier invoice becomes a known, predictable input you can build into your own per-document or per-seat pricing model, rather than an opaque line item buried in cloud infrastructure spend. See the cost-per-page economics guide for how to model this against building your own OCR infrastructure.
How it fits into your AP workflow
A supplier invoice lands in your platform
Email inbox, upload widget, or a vendor portal — wherever your product already receives documents.
Your ingestion pipeline calls /extract
One POST with the file; structured JSON with fields, line items and confidence scores comes back.
Your product applies its own confidence threshold
High-confidence invoices flow straight into your matching/approval logic; low-confidence fields route to a review queue.
Approved invoices post to the ledger
Directly as JSON your platform already consumes, or exported via /export to Xero, QuickBooks, DATEV and 11 more targets if you need a file handoff.
A worked integration: PDF to ledger-ready row
An AP platform receiving a supplier's invoice by email forwards the PDF attachment straight to /extract. The response carries a supplier name, invoice number, five line items and an overall confidence score of 0.97 — above the platform's 0.9 auto-post threshold, so the invoice flows directly into the matching logic against an open purchase order without a human touching it.
| Step | Result |
|---|---|
| Extraction | 0.4 seconds, 2 pages, $0.08 |
| Overall confidence | 0.97 — above the platform's 0.9 auto-post threshold |
| PO match | Matched automatically against open PO #4471 by the platform's own logic |
| Human review needed | No — posted directly to the approval queue |
A second invoice from a new supplier the platform has never seen — a scanned fax with a slightly skewed line-item table — comes back with an overall confidence of 0.81. Below the platform's threshold, it's routed to a reviewer with the two specific low-confidence fields highlighted, rather than the whole document flagged as suspect.
Build vs. buy, side by side
| Building it yourself | Calling this API |
|---|---|
| A general OCR service plus your own parsing, line-item reconstruction and confidence logic | One typed invoice schema back from a single call |
| Engineering time measured in months, plus ongoing maintenance as new supplier layouts appear | Integration typically working within a day or two |
| Infrastructure to host, monitor and scale yourself | No infrastructure — usage-based pricing, no servers to run |
| Your team owns every accuracy regression | Extraction quality is this API's core product, improved independently of your release cycle |
Neither side of this table is universally right — a platform with unusually specific extraction needs, deep in-house OCR expertise, and the runway to invest in it can end up with a better-fitted system by building. Most AP platforms, especially before they've reached the volume where a custom system pays for itself, are better served spending that engineering time on the parts of the product that actually differentiate it — approvals, matching logic, the review experience — rather than on invoice OCR.
Accuracy and confidence scoring
Field accuracy sits around 99% on standard invoice layouts — machine-generated PDFs from a supplier's own billing system. Accuracy on a scanned or photographed invoice can vary more, which is exactly why every field carries its own confidence score rather than a single pass/fail signal for the whole document.
That per-field granularity matters specifically for an AP platform's review queue design — a document with one uncertain field (a smudged tax rate, say) doesn't need the same review effort as one where extraction genuinely struggled throughout. Routing only the specific uncertain fields to a reviewer, rather than the entire document, is what keeps a review queue proportional to actual risk instead of ballooning with every borderline invoice.
Export formats and accounting targets
Beyond raw JSON, the same extracted invoice can be exported directly to xlsx, csv, or import-ready files for Xero, QuickBooks, Sage, DATEV, Zoho Books, NetSuite, MYOB, FreshBooks, FreeAgent and Wave — 14 targets in total.
curl -X POST https://flowparse.io/api/v1/export \
-H "Authorization: Bearer pf_live_xxx" \
-H "Content-Type: application/json" \
-d '{ "format": "xero", "type": "invoice", "data": { ... },
"options": { "xeroMode": "ACCPAY", "accountCode": "400" } }'
# → { "format":"xero", "filename":"xero-invoices.csv",
# "content":"ContactName,InvoiceNumber,InvoiceDate,...",
# "preview": { "columns":[...], "rows":[...], "notes":[...] } }This matters if your AP platform serves customers on different accounting systems and would otherwise need to write and maintain its own exporter for each one — the export layer is already built and versioned independently of your release schedule.
Errors and rate limits
| Code | Meaning |
|---|---|
| 400 | Malformed request body or unsupported format |
| 401 | Missing, invalid or revoked API key |
| 422 | No extractable data in the supplied document |
| 429 | Page balance exhausted — top up to continue |
| 500 | Unexpected error generating the response |
There's no request-per-second throttling to design around — the only limit is your page balance, which tops upinstantly on payment confirmation, so a burst of invoices arriving at month-end doesn't need special-cased handling in your ingestion pipeline.
From MVP to production volume
A platform integrating this API for the first time typically starts by routing a handful of test invoices through /extractmanually, confirming the schema matches what their matching logic expects, then wiring it into their real ingestion pipeline once the confidence-threshold routing is tuned to their customers' risk tolerance.
From there, volume scales without any change to the integration itself — the same call handles ten invoices a day or ten thousand, since pricing and throughput are usage-based rather than tied to a fixed infrastructure tier your platform would otherwise need to provision and monitor ahead of demand.
Who this is for
AP2P / procure-to-pay SaaS founders
An extraction layer under your product from day one, without a multi-quarter OCR build before you can onboard your first real customer.
Engineering teams evaluating build vs. buy
A concrete API to prototype against before committing engineering roadmap to an in-house extraction system.
Platforms migrating off a general OCR service
An invoice-typed schema replacing a hand-built parsing layer sitting on top of Textract or Document AI.
Vertical SaaS adding an AP module
Invoice extraction embedded as a feature inside a broader product, without becoming a dedicated OCR engineering team.
Why teams stop maintaining their own OCR
Invoice extraction looks deceptively finished the day it ships — a demo with a handful of clean test invoices works well, and it's easy to conclude the hard part is done. The actual cost shows up months later, as new customers bring new suppliers with invoice layouts nobody tested against, and each one becomes a bug report instead of something the extraction engine simply handles.
That ongoing accuracy maintenance is the part that's genuinely hard to staff for inside an AP platform team, whose actual differentiation is supposed to be the workflow — approvals, matching, the review experience — not OCR research. Treating extraction accuracy as someone else's core product, continuously improved independently of your own release cycle, is what most teams end up concluding after they've run the in-house version for a year or two.
This isn't unique to invoices — it's the same reason most SaaS products call a payments API instead of becoming a payment processor, or an email API instead of running their own mail infrastructure. Document extraction is reaching the same point: a well-defined, swappable layer rather than something every AP platform needs to build in-house to compete.
Get your API key
Grab a free API key and run a real supplier invoice through /extract before committing to anything — no credit card required to see the response shape on your own document.
Security and privacy
Uploads are encrypted with TLS from end to end.
Processing runs on infrastructure with SOC 2-aligned controls.
Original documents are deleted shortly after processing.
Nothing you upload is ever used to train AI models.
For a platform processing its customers' supplier invoices, that matters as much to your own customers' trust as to yours — full details are on the security page.