parsr.

How parsr ships

New format? 48 hours.

We don't train models. We curate prompts. Here's why that matters for the formats your customers throw at you.

01 / How everyone else does it

Train a model. Ship in months.

The traditional way to ship a document parser is to train one. You collect a thousand or more labelled examples per document type, stand up a fine-tuning pipeline, run evals, ship a model artifact, and roll it into production. It's a real engineering discipline and the people doing it are good at their job — but the timeline it produces is the timeline of a model release.

Mindee, one of the most established players in this space, shipped nine new pre-trained models in 2024. Across twelve months, that's roughly one new format every five weeks. That cadence is what the economics of training force on you, not a sign that anyone is slacking.

The other side of that coin is what happens when a formatchanges — a bank rolls a new column layout, a payroll system reorders sections, an invoice template gets a redesign. Every change is a re-training project on its own. New labels, new evals, new release. Weeks, not hours.

02 / How parsr does it

Curate prompts. Ship in 48 hours.

Frontier vision LLMs — Claude Sonnet 4.x, Gemini 2.0 Flash, GPT-4o — already read arbitrary document layouts out of the box. The engineering work isn't teaching them what an invoice looks like. It's making sure that when a model reads your customer's specific bank statement or payslip, the output is structured, schema-valid, and self-checking.

For each format we support, we curate four artifacts: the JSON schema we extract against, the system prompt with few-shot examples, a set of domain-specific validators (balance-chain, net-pay-match, totals-reconcile), and a fixture library of 10–50 anonymized real-world test docs. That's the parser.

From a customer-supplied sample to a working endpoint is typically two days of engineering. When a format changes — KBC adds a column, an invoice template gets a refresh — we patch the prompt and validators in about four hours and re-run the fixture suite to be sure nothing regressed.

parsers/bank_statement/kbc/what we curate
parsers/bank_statement/kbc/
├─ schema.json        # the JSON Schema we extract against
├─ prompt.md          # system prompt with few-shot examples
├─ validators.py      # balance-chain, IBAN checksum, period bounds
└─ fixtures/          # 10–50 anonymized real-world test docs
   ├─ retail_nl_2025_01.pdf
   ├─ retail_fr_2025_03.pdf
   ├─ corporate_en_2024_12.pdf
   └─ ...

03 / What you get

Velocity, made discoverable

01 / New bank

Belfius? Live in 2 days.

Customer asks for a bank we don't list yet. They send a sample. We curate the schema, prompt, and a fixture set, run it against a held-out evaluation, and ship a regional endpoint. Two days, end to end, is the typical case for a single-country retail bank.

02 / Format change

KBC reformat? Patched in 4 hours.

A bank rolls a new column layout in production. The fixture suite catches the regression on the next nightly run. We update the prompt, add the new layout to the few-shots, re-run the validators against the fixture library, and ship the patch the same business day.

03 / New doc type

New doc type? POC in a week.

Brokerage statements, lease agreements, customs declarations — anything we don't ship yet. POC in roughly a week, specialist endpoint in two. The schema and validator design is the engineering work; the model is doing the reading.

04 / How to request

What we need from you

No portal. No ticket queue. No "submit an RFE and we'll get back to you in two weeks." Email, sample, timeline, ship.

  1. 01

    Email support@tryparsr.dev with the format you need

    Bank, payslip system, invoice issuer, receipt category — whatever your customer is throwing at you. One sentence about the use case is plenty.

  2. 02

    Attach a sample document

    PDF, JPG, or HEIC. Anonymized is fine — replace names, account numbers, and totals with realistic-looking placeholders. We need the layout, not the data.

  3. 03

    We respond within 24 hours with a timeline

    If it's a known format, the timeline is hours. If it's a new layout, it's days. If it's a brand-new document type, we'll tell you that too — and what we'd need to scope it.

  4. 04

    Tested + shipped within 48 hours typical

    Schema, prompt, validators, fixtures. Released to your region (EU or US) and reflected on the changelog page that same day.

  5. 05

    Free for design partners and Growth tier+ customers

    Format-curation work on Growth (€199/mo) and above is included. Design partners — early customers willing to share fixtures — get it on Starter too.

05 / Recent

Format changelog (last 30 days)

A representative slice of what shipped between 2026-04-09 and 2026-05-09. The full engineering log lives at /changelog.

  • 2026-05-09Added Argenta (BE) bank statement support
  • 2026-05-08Updated Belfius parser for new transaction column layout
  • 2026-05-07Added Boursorama (FR) bank statement support
  • 2026-05-05Added Caisse d'Épargne (FR) bank statement support
  • 2026-05-04Schema bump: bank_statement.v1 → v2 (added per-field confidence + bbox)
  • 2026-05-02Added Crédit Agricole (FR) regional bank statement variants
  • 2026-04-30Added DATEV (DE) payslip support — German tax-class categorization
  • 2026-04-28Added Loket (NL) payslip support
  • 2026-04-25Added Triodos Bank (NL) bank statement support
  • 2026-04-22Added Sage Paie (FR) payslip support
  • 2026-04-19Validator added: net-pay-match for payslip schema
  • 2026-04-15Added bunq (NL) bank statement support
  • 2026-04-12Added Commerzbank (DE) bank statement support
  • 2026-04-09Added Sparkasse Köln/Bonn (DE) regional variant

Try parsr on a format we don't list yet.

We'll ship it for free if you become a design partner. Email a sample, we'll come back with a timeline within 24 hours.

Subscribe to changelog