How it works
Drop a PDF. See where your money went.
No “connect your bank” step, no aggregator sitting between you and your accounts. You hand Pare a statement you already have, and it does the reading, the math, and the categorizing. Here's the whole pipeline, start to finish. (Want automatic sync anyway? There's an opt-in SimpleFIN connection — off by default, read-only, and paid for and revocable by you.)
Drop a PDF
Export a statement from your bank and drag it in. No login, no aggregator, no MFA. PDF parsing is tuned today for Amex Gold, CIBC Aeroplan Visa, and CIBC chequing — more banks ship as their parsers are verified — and any bank works via an OFX/QFX export.
We parse it in seconds
A Python parser runs in a Cloudflare Container: it extracts the text, reads every transaction, and reconciles the running balance against the statement's own summary so totals can't silently drift. Rules categorize each row, and your corrections teach the rules. The PDF is deleted the moment parsing finishes.
See where your money went
Your dashboard is built on import: spend by category, this month versus last, detected subscriptions, and your savings rate. No pivot tables, no manual tagging.
Balance-reconciled, not best-effort
Parsing a statement is easy to get quietly wrong — a missed row, a transposed date, a credit read as a charge. Pare's ledger engine ties the running balance it computes back to the balance the statement prints. When a row doesn't reconcile, it's skipped and logged rather than folded into a wrong total. You get missing rows you can see, never corrupted numbers you can't.
Categorization that learns
Categories are assigned on parse by a first-match-wins rule list, so a 300-line statement is sorted the second it lands — you don't touch 300 dropdowns. When you re-file a merchant, that correction becomes a rule and re-applies to everything, including past transactions. The taxonomy is generic in the open-source code; your tuned rules live only in your database.
Under the hood
For the curious: the whole thing runs on Cloudflare. Nothing here is proprietary black-box magic — it's the parser you can read on GitHub and run on your own machine.
Next.js 16 on Cloudflare Workers
The app itself — pages and API run at the edge.
Per-user Durable Object (SQLite)
One private database per account. No shared table, no cross-account query.
R2 object storage
Holds an uploaded PDF only until it's parsed, then drops it.
Queues
Hand the parse job off so the upload returns immediately and retries survive a blip.
Python parser in a Container
The same parser you can run locally, isolated per job and asleep when idle.
Same code, two shapes: the hosted app splits the parser into a Container and the database into a per-user Durable Object; self-host collapses both into one local process over a SQLite file. The parsing logic is identical either way.