DEV Community: Christian Rousseau

Parsing Receipts, Invoices & Bank Statements With an API (Developer Guide, 2026)

Christian Rousseau — Thu, 18 Jun 2026 10:05:31 +0000

If you're building an expense tracker, AP automation, a bookkeeping integration, or an AI agent that handles documents, you hit the same problem: receipts, invoices and bank statements arrive as PDFs and images, and your code needs structured data.

Here's how to do document parsing properly in 2026 — the patterns that hold up in production, and the glue you should not hand-roll.

Why not just call a vision LLM directly?

You can POST an image to a vision model and ask for the fields. It mostly works — until it doesn't:

You get prose or loosely-shaped JSON you still have to parse and validate.
The schema drifts between calls, so downstream code breaks.
No confidence signal — you can't tell a clean extraction from a hallucinated one.
No handling for failed parses, retries, or per-document billing.

You end up rebuilding all that glue. A purpose-built parsing API gives it to you out of the box.

What a good document-parsing API gives you

A stable, typed schema every time: a receipt returns merchant, date, currency, subtotal, tax[], total, category; a statement returns account metadata, period, and transactions[{date, description, amount, balance}].
A confidence score + needs_review flag, so you auto-process high-confidence docs and route the rest to a human.
Validation (totals add up, dates normalized to ISO) before data reaches your DB.
Sane billing: failed parses aren't charged.

Integration patterns

HTTP API — POST image_url or image_base64, get JSON. The 80% case.
MCP server — so an AI agent can call parse_document as a tool, no glue code.
n8n / Make / Zapier — a workflow node for no-code automation (Gmail attachment → parsed row → Sheet).
x402 micropayments — pay per call in USDC, no API key, for agent-to-service payments.

A minimal call

curl -X POST https://parsedoc.wrapper-agency.com/api/demo \
  -H "Content-Type: application/json" \
  -d '{"image_url": "https://example.com/receipt.jpg"}'

You get back the same JSON shape every time, with a confidence score.

Production tips

Route by confidence. Auto-post docs above ~0.9; queue the rest. Don't trust silent extraction.
Validate before you store. subtotal + tax = total; sum(line_items) = subtotal. Reject mismatches.
Dedupe invoices on vendor + invoice_number so retries don't double-record.
Keep documents out of logs — for financial data, prefer a service that processes in memory and stores nothing.

Where ParseDoc fits

I built ParseDoc around exactly this: a stable JSON schema for receipts, invoices and bank statements, with confidence scoring, an OpenAPI spec, an MCP server (parsedoc-mcp), an n8n node (n8n-nodes-parsedoc), and x402 pay-per-call. Free tier (10 pages/day) to test, nothing stored, failed parses never billed. Disclosure: it's mine. Whatever you pick, the principles above are what separate a demo from something you can run in production.

How to Extract Invoice Data Into a Spreadsheet for Accounts Payable (2026)

Christian Rousseau — Mon, 15 Jun 2026 21:28:09 +0000

If you handle accounts payable, you know the grind: supplier invoices arrive as PDFs (or worse, scans), and someone has to retype vendor, invoice number, date, amount and tax into your accounting system or a spreadsheet. A handful is annoying; hundreds a month is a full-time data-entry job with errors baked in.

Here's how to get invoice data into a spreadsheet (or your AP tool) reliably in 2026 — the fields that matter, the order of operations, and the checks that stop bad data from reaching your books.

The fields AP actually needs

For each invoice, capture at minimum:

Vendor — the supplier name.
Invoice number — the supplier's reference. Vendor + invoice number = your dedupe key; keep both so you never pay the same invoice twice.
Invoice date and due date — the due date drives your payment run, so capture it even when it's only implied by terms ("Net 30").
Subtotal, Tax, Total — keep tax separate for VAT/GST reclaim and correct posting.
Line items (optional) — description, quantity, amount per line, only if you need item-level detail for inventory or job costing.

The order of operations

Header-level first. Most AP teams post at header level (vendor / date / number / total) and only itemize when they must. Don't capture line items you won't use.
Normalize the date. Pick one format (YYYY-MM-DD) so sorting and import don't choke.
Validate the math. Sum of line items should equal the subtotal; subtotal + tax should equal the total. If it doesn't, the extraction missed something — fix it before it hits the ledger. At scale, build this check in: extraction at scale means errors at scale without it.

Getting the data out of the PDF

Consistent layouts (a few repeat vendors): a template-based parser works — set the zones once, reliable as long as the layout never changes.
Varied layouts (many vendors, international, inconsistent formats): template parsers break constantly and you spend more time maintaining templates than you save. Vision-AI extraction handles arbitrary layouts far better because it reads the document, not a fixed position.
Already in an automation stack (n8n, Make, Zapier): do the extraction as a workflow step so data lands in your sheet/ERP automatically instead of export-and-reupload — that's where the real time savings are.

Where an AI tool fits

I built a free one for the extraction step: ParseDoc turns invoice PDFs or photos into structured data (vendor, invoice number, date, subtotal, tax, total, plus line items) as clean CSV/JSON — 10 pages/day free, nothing stored, with an HTTP API and an n8n node if you want it inside a flow. Disclosure: it's mine. Docparser (template-based) and others occupy the same space, so test 10–20 of your actual invoices before committing — extraction quality varies a lot by document type, and you want to see it on your docs.

The bottom line

Decide your fields (header-level unless you need lines), normalize dates, and validate subtotal + tax = total before anything reaches your books. For varied layouts, vision-AI beats template parsers; for volume, wire it into your automation. Do that and AP stops being data entry and becomes a quick review.

How to Get Receipts Into a Spreadsheet Without Typing (2026 Guide)

Christian Rousseau — Sun, 14 Jun 2026 21:36:07 +0000

Every freelancer, bookkeeper and small-business owner eventually hits the same wall: a pile of receipts, and a spreadsheet that needs every line typed in by hand. It's slow, error-prone, and exactly the work nobody wants to do at 11pm before a tax deadline.

This guide covers the practical ways to get receipt data into Excel or Google Sheets in 2026 — what to try first, the fields that actually matter, and how to keep the result clean enough to hand to an accountant.

The fields you actually need

Before you capture anything, decide your columns. For most expense and bookkeeping work, the useful set is:

Date — normalized (YYYY-MM-DD sorts correctly).
Merchant — who you paid.
Subtotal, Tax, Total — keep tax separate; you need it for VAT/GST reclaim and to see the deductible portion.
Category — meals, travel, software, office… so a pivot table writes your summary for you.
Currency — essential if you travel or buy from abroad.

A spreadsheet with those columns is something an accountant can actually use. A photo in your camera roll is not.

Method 1: Use a native export when one exists

Some receipts you never need to retype, because the source already has the data:

Amazon — Order History Reports export your orders to CSV.
Uber / Lyft — trip history can be downloaded.
Card statements — your bank or issuer usually offers a CSV/QFX export of transactions.

The catch: these only cover your own account, and a statement line ("AMZN $43.38") doesn't tell you what you bought or how much tax you paid. For anything that arrives as a paper slip, an emailed PDF, or a photo, you still have to extract it.

Method 2: Type it by hand (and why to avoid it)

Manual entry is fine for five receipts. For fifty, it's hours of work plus a guaranteed handful of transcription errors — a transposed total here, a wrong date there — that surface during reconciliation when they're hardest to find. If you do this monthly or for clients, it doesn't scale.

Method 3: Vision-AI extraction (the 2026 way)

Modern tools read a receipt the way a person does — they look at the image, find the merchant, the date, the totals and the tax, and output structured data. Unlike old template-based OCR, vision models handle crumpled paper, phone photos, foreign languages, and layouts they've never seen.

The feature to look for is a confidence score per field. Good extraction tells you which receipts it wasn't sure about (the blurry ones), so you check those and trust the rest. Silent guessing is worse than an honest "needs review."

A practical workflow:

Photograph receipts as you go (faded thermal paper doesn't survive a drawer).
Batch-convert them to one CSV.
Sort by confidence; eyeball the low-confidence rows against the originals.
Add an FX-rate column if you have multiple currencies.
Pivot by category for your report.

If you want to try this without installing or signing up for anything, I built a free tool for exactly this step — ParseDoc turns receipt photos or PDFs into a clean CSV (merchant, date, subtotal, tax, total, category, confidence), 10 pages a day free, nothing stored. Disclosure: it's mine. There are other solid options (Veryfi, Dext and others occupy the same space), so run a handful of your real receipts through a few and see which output is cleanest before committing.

For teams and automation

If receipts flow through email or a shared inbox, you can skip the manual step entirely: an automation (n8n, Make, Zapier) can watch the inbox, extract each attachment, and append a row to your sheet or accounting tool. That turns "month-end receipt panic" into a background process you never think about.

The bottom line

Decide your columns, prefer a native export when the source offers one, and for everything else use vision-AI extraction with a confidence check — then reconcile before you trust the file. Do that and a job that used to eat an evening becomes a few minutes, with numbers your accountant won't bounce back.

How to Convert Bank Statement PDFs to CSV for QuickBooks & Xero (2026)

Christian Rousseau — Sat, 13 Jun 2026 20:36:19 +0000

If you've ever tried to import a bank statement into QuickBooks Online or Xero, you already know the dirty secret of bookkeeping: the bank gives you a PDF, and your accounting software wants a CSV. Between those two formats lies an afternoon of copy-pasting, broken columns, and reconciliation errors that don't show up until month-end.

This guide walks through the right order of operations — what to try first, what actually breaks, and the format details QuickBooks and Xero quietly expect. It's written for bookkeepers and small-business owners who just want clean transactions in their ledger without drama.

Why PDFs break (and why it's not your fault)

A PDF is a layout format, not a data format. It describes where ink goes on a page, not what a column means. When you open a statement, your eye groups the date, description, and amount into a tidy row. The file underneath has no idea those things belong together.

There are two flavors of PDF, and they fail differently:

Text-based PDFs (generated by the bank's system) contain selectable text. Copy-paste sometimes works, but columns collapse, multi-line descriptions split, and negative amounts lose their parentheses.
Scanned or image PDFs (a photo of a paper statement, or a "print to PDF" of a scan) contain no text at all — just pixels. Copy-paste gives you nothing. You need OCR (optical character recognition) to read them.

On top of that, every bank lays out its statement differently. Some put debits and credits in separate columns; some use one signed column; some bury the running balance on the right; some wrap long merchant names across two lines. A converter that works perfectly on Chase may mangle a Wells Fargo or a European IBAN statement. This is why "just export to Excel" rarely works on the first try.

Step 1: Try the bank's native export first — always

Before you convert anything, log into your online banking and look for a download option. Most banks offer one or more of these:

CSV — comma-separated values, the cleanest option.
QFX / OFX — Quicken/Open Financial Exchange, designed specifically for accounting import.
QBO — a QuickBooks-flavored variant of OFX (Web Connect).

If your bank offers QFX or QBO, use it. These formats carry transaction data as structured fields, so QuickBooks and Xero import them directly with category mapping and far fewer errors than a CSV. QFX even includes a unique transaction ID that helps your software avoid creating duplicates.

A few practical notes:

Native exports usually only go back 90 days to 24 months. For older history, the PDF may be your only source.
Download the full date range in one file when you can. Splitting by month invites gaps and double-counted edge transactions.
If you only see PDF and Excel options, grab the PDF — it's the most faithful record — and plan to convert it.

The PDF-to-CSV path exists because native export isn't always available: closed accounts, old statements, foreign banks, or institutions that simply never built the feature. That's where a converter earns its keep.

Step 2: Understand the 3-column format QBO and Xero expect

Both QuickBooks Online and Xero accept a simple CSV for bank transactions, and both are happiest with a three-column structure:

Date	Description	Amount
2026-01-04	COFFEE ROASTERS LLC	-4.75
2026-01-05	CLIENT PAYMENT — INV 1042	1,200.00

That's the core. A few rules make or break the import:

Date format consistency. Pick one format (YYYY-MM-DD is safest) and use it for every row. Mixing 01/04/26 and Jan 4 2026 will cause the importer to reject rows or misread the month/day order.
One header row, no blank rows, no summary lines. Delete the "Opening Balance," "Total Debits," and "Page 2 of 4" junk that statements love to include. The importer treats every row as a transaction.
No currency symbols or stray text in the Amount column. $1,200.00 should become 1200.00. Thousands separators (1,200) confuse some importers — strip them if you hit errors.

Xero supports a four-column variant too, splitting money into separate Debit and Credit columns instead of one signed Amount. QuickBooks Online supports both 3-column and 4-column layouts during its CSV import wizard. Either is fine — just be consistent within a single file, and know which one you're producing.

Step 3: Watch the signed-amount gotcha

This is the single most common reason an import "works" but the books are wrong.

In the three-column format, money out must be negative and money in must be positive. A $50 purchase is -50.00. A $200 deposit is 200.00. Get the sign backwards and your software will record expenses as income — your bank balance will still look plausible, but every category is inverted.

Where it goes wrong:

Parentheses. Many statements show debits as (50.00) rather than -50.00. Accounting convention reads parentheses as negative; a naive converter reads them as the number 50. Confirm those become negatives.
Separate debit/credit columns. If your statement has two money columns and you're flattening to one signed Amount, the debit column must be negated and the credit column kept positive. Mixing them up flips everything.
Refunds and reversals. A refund is money in (positive) even though it sits in a column full of purchases. Spot-check a few.

If you use the four-column (Debit/Credit) format instead, you sidestep the sign question — but then make sure no amount accidentally lands in both columns.

Step 4: Reconcile the balance before you import

Never trust a converted file until it ties out. This one check catches almost every error — dropped rows, doubled rows, sign flips, OCR misreads:

Opening balance + sum of all transaction amounts = closing balance.

Take the opening balance printed on the statement, add the total of your Amount column (negatives included), and confirm it equals the closing balance on the statement. If it matches to the cent, your conversion is sound. If it's off:

Off by one transaction's value → a row was dropped or duplicated. Find it.
Off by exactly 2× a transaction → a sign is flipped (a -50 that should be +50 moves the total by 100).
Off by a round, repeating amount → a thousands separator or currency symbol got misparsed.

Many statements also print a running balance per line. If yours does, keep it during QA: each row's running balance should equal the previous row's balance plus the current amount. That makes a bad row obvious at a glance. You can drop the running-balance column before importing — QuickBooks and Xero don't need it — but it's the best debugging tool you have.

Step 5: Where an AI converter fits

For text-based PDFs from a major bank, free desktop tools or the bank's own export will often do. The pain shows up with scanned statements, photos, foreign-bank layouts, or odd column structures — exactly the cases that need OCR plus an understanding of what each column means.

This is where vision-AI converters help. Instead of relying on fixed templates per bank, they read the page the way a person would: identifying the date, the description, the signed amount, and the running balance regardless of layout or language, then outputting clean CSV or JSON.

If you want to test the approach without signing up for anything, ParseDoc offers a free tool — 10 pages a day, no account, and nothing is stored (files are processed in memory and discarded). It handles any bank layout and outputs the date, description, signed amount, and running balance ready for QuickBooks, Xero, Excel, or Google Sheets. For higher volume there are paid plans, an n8n node, and an API, but the free tier is enough to convert a statement or two and check it against the reconciliation test above. It's one option among several — DocuClipper, MoneyThumb, and others occupy the same space — so try a sample page and see whether the output ties out before committing to any tool.

Whatever you use, the workflow doesn't change: native export first, three-column format, fix the signs, reconcile the balance, then import. Do those four things and a task that used to eat an afternoon becomes a five-minute job — with books you can actually trust.