One cash sheet across every
bank, entity, and currency.
Three banks, three entities, three currencies reconciled into one canonical sheet. Balances polled hourly, statements parsed on arrival, every row owned by exactly one writer. The cash position lives somewhere reliable, not in nobody’s head.
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.
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.
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.
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.
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.
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.
Trust is structural, not promised.
Treasury work has a low tolerance for surprise. The system is designed so that safety lives in the architecture, not in assurances.
No credential ever reaches the LLM.
API tokens, bank PDF passwords, and service-account keys live in a dotenv file. Python handles every API call and every file decrypt. A prompt injection in a statement memo cannot exfiltrate a credential, because the credential is never in the prompt.
Each row has exactly one owner.
Every row on the canonical sheet is owned by one writer, keyed by bank, entity, currency, and account. No two jobs ever write the same cell. Two writers cannot race because, architecturally, there is never more than one.
Real-time signals never overwrite the sheet.
SMS alerts and transaction pings are notification-only. They tell you something happened; they never update the canonical balance. The daily statement remains authoritative, and the sheet only moves when the authoritative source does.
Every row traces back to its source.
Every upsert logs its origin: API payload hash, PDF filename, cursor position, timestamp. If a balance on the sheet looks wrong, the debug path is mechanical: pick the row, open the log, read the source.
The sheet never goes stale without saying so.
Each feed reports its last-successful-pull timestamp alongside the balance. If a bank API goes down, the row is clearly flagged as stale, not silently carried forward. You know when you’re looking at fresh data.
What you give it, what you get back.
- 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
- 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.
How much does it cost?
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.
Which banks does it work with?
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.
Why a canonical sheet instead of an ERP module?
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.
What about audit trail and compliance?
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.
How fast is rollout to production?
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.
Do you need our banking credentials?
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.
How does it handle FX and multi-currency balances?
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.
Can we start small?
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.