One cash sheet across every
bank, entity, and currency.
Stop copy-pasting balances between four browser tabs.
If your business runs across multiple entities, multiple currencies, and multiple banks, the cash position lives in nobody’s head reliably. Somebody pulls statements in the morning, someone else reads the treasury tab in each banking portal, and the CEO gets a stale number on a Slack DM when they ask.
This blueprint replaces that ritual with a single canonical sheet. Each bank is polled on its own cadence. Each row is owned by exactly one writer. The numbers on the sheet are never more than an hour old, and nobody overwrites anybody.
Translated to your operation: the CEO opens one tab and sees the truth. The finance team stops being the lookup desk. The monthly close starts from a clean snapshot instead of a scavenger hunt.
Proof from the channel.
What lands in the HKR finance Slack every morning at 9:30: the BT daily statement, parsed into the canonical balance sheet. No tab-hopping, no copy-paste.
Live post · 27 May 2026 · #treasury
Why it matters.
When cash across three entities lives in nobody’s head reliably, every decision waits on a manual lookup. The fix is not faster lookups. The fix is a sheet that’s already right.
One canonical source, always freshThe work of consolidating balances is mechanical, it breaks down at scale, and the cost of a stale number compounds: payroll cut against the wrong pot, vendors paid from the wrong entity, FX decisions made on yesterday’s truth. The data is in each bank’s portal; the problem is that no one has time to pull it four times a day.
Speed matters too. When the CEO asks “how much EUR do we have this week?”, the answer is already in the sheet, already attributed, already reconciled to the underlying statement. Decisions that used to wait for a weekly review happen on the day the balance shifts.
How it actually works.
Four steps, on a 5-minute heartbeat. Each bank handled in its own lane, each row owned by exactly one writer.
1 · Pull
Each bank is polled on its own cadence: API banks return balances across every profile and account, file-based banks drop encrypted daily statements into a dedicated inbox. Each feed is a separate job, isolated from the rest.
Per-bank cadence · isolated failure modes
2 · Decrypt & parse
File-based banks: the PDF is decrypted with the stored password, regex extracts balances per IBAN, whitelist match against the known accounts. API banks: the JSON is parsed into the same canonical shape. One schema, many sources.
Deterministic Python · no LLM in this layer
3 · Upsert canonical row
Each writer owns its rows by bank-entity-currency-account tuple. No writer ever touches another writer’s rows. Two pullers cannot race for the same cell, by design.
Single-writer rule · no overwrite conflicts
4 · Trace
Every upsert logs its source: API payload hash, PDF filename, cursor position. If a number on the sheet looks wrong, the debug path is mechanical: follow the row back to the feed that wrote it.
Append-only state · every row traceable
What you give it, what you get back.
You give it
- API or email access to each of your banks (API keys, JWT setups, or a dedicated inbox for daily statements)
- A Google Sheet or database you want used as the canonical balance view
- A list of entities, currencies, and accounts you track
- One trusted human (CEO, COO, or finance lead) who reads the sheet
You get back
- One canonical sheet, one row per bank-entity-currency-account, refreshed hourly
- Per-row freshness timestamps so you always know when the last pull succeeded
- Isolated per-bank jobs so a single failure never drags down the rest of the sheet
- A full append-only audit trail from every cell back to its API or PDF source
This blueprint fits when…
You operate across multiple entities, multiple currencies, and multiple bank accounts, and the cash position lives in nobody’s head reliably.
Your bank stack is a mix of modern (API) and legacy (PDF statements, SWIFT, emailed reports), so you need both worlds on the same sheet.
Somebody on the team spends 20 to 40 minutes a day copy-pasting balances between portals and a spreadsheet.
Decisions you’d like to make on current cash (payroll timing, vendor batches, FX moves) wait on a manual refresh.
Single-bank, single-currency, single-entity. The leverage scales with complexity.
Your existing ERP already gives you a real-time consolidated view and you trust the numbers.
Questions you’re probably asking.
It depends on the shape of your stack: how many banks, which ones need a custom adapter, how many entities and currencies you track. We walk through pricing on the first call, once we’ve scoped the work. Pilots are fixed-fee; ongoing operation scales with the number of feeds. No surprise invoices, no hidden line items.
Anything with an API (Wise Business, Revolut Business, Stripe Treasury, Mercury, Brex and most modern providers) works out of the box. Legacy banks with encrypted PDF statements, SWIFT MT940, or emailed reports get a thin adapter during the pilot. If you’re unsure, the fit call will confirm it in five minutes.
An ERP gives you accounting truth, not cash truth. Accounting truth is slow, closed monthly, and authoritative. Cash truth is what’s in the accounts right now. The canonical sheet lives between them: hourly-fresh, reconcilable to the accounting system, readable at a glance. We don’t replace your ERP; we make the live view reliable enough to act on.
Every pull, every upsert, and every statement ingest is traceable end-to-end. Cursor advances, file hashes, and writer timestamps all persist in append-only state files. Credentials never touch an LLM; they live in environment-level storage, read only by Python code. If your auditor asks “why was this balance $47,209 on the 14th?”, the answer is a mechanical trace back to the source payload.
Typically two weeks from signed scope to a live sheet. Week one: adapter build for each bank, schema mapping, and a dry-run against historical data to tune the parsing. Week two: supervised operation with your finance lead verifying each row against the bank portal. After that, the sheet runs on its own rhythm.
Yes, but they never leave your environment or touch any LLM. Credentials live as environment variables in infrastructure you control (your cloud, your VPN, your on-prem) and are only read by the Python scripts that make API calls. For file-based banks, you can skip API credentials entirely and use an emailed statement flow.
Each currency gets its own row. We never convert balances on the sheet; you always see what’s actually in the account. If you want a consolidated view in a home currency, we add a derived row using a rate source of your choice (ECB, exchange rate from your accounting system, or the bank’s own rate), and we label it explicitly as derived.
Yes. The pilot is typically one or two banks across a single entity. Once you see the sheet running and trust the numbers, you decide whether to expand to more banks, entities, or currencies. No multi-year commitment to find out if this fits.
Want this on your treasury?
This blueprint is live in production today. If you operate across multiple entities and currencies and want a canonical cash view you can actually trust, we can scope a version for your operation in a 30-minute call.