Why firms pick parsr

Built for the firm, not the bookkeeper-of-one

The firm workflow

Five steps from client portal to ledger

Designed around the way modern firms already work — a client portal, a dispatcher, a bookkeeping system, and a senior reviewer for the edge cases.

1. 01

   01 / client.upload(documents)

   Client uploads bank statements, invoices, and receipts to your firm's portal — typically batched at month-end, sometimes streamed daily. Your portal stores the raw files, tagged with client_id and document_type.

2. 02

   02 / firm.dispatch(file, org_id=client_id)

   Your dispatcher service forwards each file to the matching parsr endpoint — /v1/parse/bank-statement, /v1/parse/invoice, or /v1/parse/receipt — passing the client's id as metadata.org_id. The same parsr API key works for every client; isolation is at the metadata layer.

3. 03

   03 / parsr.parse → schema-validated JSON

   parsr returns a versioned, schema-validated payload per document. Bank statements include the balance-chain verdict; invoices include line items and VAT breakdown; receipts include merchant + line items + FX hint. Every field carries a confidence score.

4. 04

   04 / bookkeeping.import(json, org_id)

   Your integration layer imports the parsed JSON into the bookkeeping system the client uses — QuickBooks Online for Accountants, Xero Practice Manager, Sage, or your firm's internal system. The org_id stays attached so the journal entry lands in the right ledger.

5. 05

   05 / reviewer.escalate(low_confidence_or_chain_failed)

   Anything below your confidence threshold (we recommend 0.85 for posting, 0.95 for VAT-bearing fields) or any failed balance-chain verdict is escalated to a human reviewer with the bounding box pre-rendered. Everything above flows straight to the ledger.

The integration

Dispatch by client, parse by document type

One firm, many clients, three document types. Each parse carries the client's org_id so audit records, billing, and retention policies stay isolated per-client without your code thinking about it.

import os
import asyncio
import httpx

API = "https://eu-api.tryparsr.dev"
KEY = os.environ["PARSR_KEY"]  # sk_eu_live_…

ENDPOINT = {
    "bank_statement": f"{API}/v1/parse/bank-statement",
    "invoice":        f"{API}/v1/parse/invoice",
    "receipt":        f"{API}/v1/parse/receipt",
}

POST_THRESHOLD = 0.85   # post straight to the ledger above this
VAT_THRESHOLD  = 0.95   # VAT-bearing fields get a stricter bar

async def dispatch(client_id: str, doc_type: str, file_path: str) -> dict:
    """Parse a single client document. client_id is your firm's internal id;
    we pass it as parsr's org_id so audit, billing, and retention scope
    stay isolated per-client."""
    url = ENDPOINT[doc_type]

    async with httpx.AsyncClient(timeout=60) as http:
        with open(file_path, "rb") as f:
            resp = await http.post(
                f"{url}?wait=60",
                headers={
                    "Authorization": f"Bearer {KEY}",
                    "Idempotency-Key": f"{client_id}:{file_path}",
                },
                files={"file": f},
                data={"metadata": f'{{"org_id":"{client_id}"}}'},
            )
        resp.raise_for_status()
        doc = resp.json()

    # Bank statements: balance-chain verdict gates auto-post
    if doc_type == "bank_statement":
        chain = doc["validation"]["balance_chain"]
        if not chain["valid"]:
            return {"action": "review", "reason": "balance_chain_failed",
                    "client_id": client_id, "doc": doc}

    # Confidence-gated routing into the bookkeeping ledger
    min_conf = min(f["confidence"] for f in doc["fields"].values())
    has_vat = any("vat" in name for name in doc["fields"])
    bar = VAT_THRESHOLD if has_vat else POST_THRESHOLD

    return {
        "action": "post" if min_conf >= bar else "review",
        "client_id": client_id,
        "schema_version": doc["schema_version"],
        "doc": doc,
    }

async def run_batch(client_id: str, files: list[tuple[str, str]]) -> list[dict]:
    """Process a client's monthly drop in parallel, scoped to their org_id."""
    return await asyncio.gather(*(
        dispatch(client_id, doc_type, path) for doc_type, path in files
    ))

What partners ask before signing

The controls your senior partner wants in writing

• Multi-tenant data isolation: one org_id per client, no shared scope
• Accountant-grade audit logs — every parse is signed and exportable as NDJSON
• DORA-compliant retention windows, configurable per-org down to zero
• GDPR-compliant with a vendor DPA available before signup, written for accountants
• EU residency by default — Frankfurt + Paris regions, no US fall-through
• Per-client billing meters, per-client rate limits, per-client retention
• Schrems II-safe: no US sub-processor sits on the parse path
• SOC 2 Type II audit window opens Q3 2026 (ISO 27001 to follow)
• Region-bound API keys (sk_eu_… vs sk_us_…) — no accidental cross-border traffic
• 30-day file-hash cache — re-uploads of the same statement don't double-bill

Pricing fit

Where firms land on the ladder

Questions firms ask

FAQ

Related

Read next

• Product

  Bank statement parser

  The endpoint, the schema, the balance-chain verdict — the workhorse of every firm's pipeline.

• Product

  Invoice parser

  Vendor invoices with VAT breakdown, line items, and currency — into the AP ledger.

• Product

  Receipt parser

  The wrinkled photo from the client's expense folder, parsed into a journal entry.

• Sovereignty

  Why parsr is EU-first

  The DORA / NIS2 / GDPR story for the partner who'll review your sub-processor list.

• Security

  Controls, DPA, sub-processors

  Vendor sheet in question-and-answer form, written for finance reviewers.

• Pricing

  The full ladder, in one page

  Where Scale and Enterprise fit, and what the Enterprise floor includes.