Provenance as a column, not a folder
Most finance data loses its origin the moment it is useful. A figure gets copied from a statement into a spreadsheet, from that spreadsheet into a summary, from the summary into a board pack — and by the third step the only thing connecting the number to a document is whoever did the copying. Entity tagging is the refusal to let that happen: the origin is a column in the data, so it survives every filter, sort, pivot and export.
In practice it means each extracted row records the file it was read from and the account that file belongs to. For a business with one company and one account, that is mildly useful. For anything with more than one set of books it changes what the data can do — because separating and combining stop being different jobs and become the same table with a filter on or off.
The tab-per-company problem
The instinctive way to handle several companies in a spreadsheet is a worksheet each. It is tidy, it matches how people think, and it fails the moment a question spans two of them. Worksheets cannot be filtered across. A pivot cannot reach into six tabs. Adding a seventh company means restructuring the file rather than adding rows.
Worse, a tab is a place rather than a value, so a mistake can hide simply by being pasted into the wrong one. Nothing in the data says which company a row belongs to — the sheet name says it, and sheet names are not checked by anything. Rows pasted one tab over are invisible until a total looks odd, which is usually months later.
Turning that sheet name into a column solves all three problems at once. Cross-company questions become filters, adding an entity becomes adding rows, and a misfiled transaction is now a wrong value in a visible field rather than a right value in the wrong place. It is a small structural change that removes an entire category of month-end confusion.
How the tagging happens
There is no setup step. You do not define entities, map accounts or fill in a configuration screen before uploading — a requirement that sounds reasonable and in practice means the first useful output is an afternoon away.
1 — Upload everything together
All companies, all accounts, all periods. Files do not need sorting or renaming first.
2 — Each row is read and labelled
Fields are recognised by meaning; the source file and account are recorded alongside them as the row is created.
3 — Review by entity
Balance checks run per statement, so the review list is already grouped by the company it concerns.
4 — Export once, use twice
One file with the tag column: filter for local books, leave it unfiltered for the group view.
Because the tag is derived from the document rather than declared in advance, it is correct by construction. A row cannot be labelled with an entity it did not come from, which is precisely the failure a manual process makes most often.
What each row carries
The provenance fields sit alongside the ordinary transaction fields, so nothing about the export feels unusual — it is a normal spreadsheet with a few extra columns that happen to be the ones that matter later.
| Field | Source | Typical use |
|---|---|---|
| Source file | The uploaded document | Walk a figure back to a statement page |
| Account | Statement header | Separate current, deposit and currency accounts |
| Entity | Derived from the account | Filter the group table to one company |
| Period | Statement date range | Cut by month without parsing dates |
| Page | Where the row was read | Point an auditor at the exact page |
| Confidence | Extraction certainty | Review the uncertain rows first |
None of these replace the transaction fields themselves — date, description, signed amount and running balance are extracted as usual and behave as usual. The provenance columns exist to answer questions about the data rather than questions in the data.
Filter down, roll up, without re-running anything
The practical test of a tagged dataset is whether you ever need to go back to the source to answer a new question. With a tab per company you usually do. With a tag column you almost never do, because the two directions people actually need — narrower and wider — are both filters on the same table.
Narrower is local bookkeeping: one company, one period, its own rows and nothing else, in a file the local accountant can import without ever seeing the rest of the group. Wider is the group view: no filter, everything together, totals by month or category across every company at once. The two are guaranteed consistent because they are the same extraction, which is not something a copy-paste workflow can promise.
It also makes the awkward middle cases easy. Three of the eight companies, for one quarter, excluding one account. That request is a five second filter on tagged data and a small project on anything else, and it is the kind of request that arrives late on a Friday.
Tracing a number back to a page
Every finance function eventually faces the same question about a figure someone else produced: where did this come from? Without provenance the honest answer is that it came from a spreadsheet, which is not an answer. With it, the chain is short and mechanical — the total came from these rows, these rows came from this file, this file is that company's statement for that month.
This matters most in the two situations where being right is not enough on its own. An audit needs evidence, not assertion; a dispute between a parent and a subsidiary about who bore a cost needs a document, not a recollection. In both, the ability to produce the source in seconds changes the conversation from an argument into a lookup.
It also protects against a quieter risk: the figure that was right when it was produced and has since been edited. Because the tag travels with the row, a value that no longer agrees with its source is detectable. A number with no source attached can only ever be trusted or not.
Several accounts inside one company
Entity and account are separate fields precisely because most companies have more than one account, and the two questions are different. How did this company perform is an entity question. Why does this account never hold a balance is an account question. Collapsing them into one label makes the second unanswerable.
Keeping them apart also handles the common structures cleanly: a deposit account that only ever receives sweeps from the current account, a euro account used for a handful of suppliers, a card account whose statement looks nothing like a bank statement. Each is tagged as its own account under the same entity, so a total rolls up correctly while the detail stays available.
Movements between two accounts of the same company deserve a mention here, because they look like income and expenditure and are neither. On tagged data they are visible as an equal and opposite pair inside one entity, which makes them easy to identify and exclude from any figure that is meant to describe trading rather than treasury.
Naming that survives a year
Tags are derived from documents, and documents are named by banks, so the raw label is rarely the name you want on a report. That is fine — the tag is data, so renaming is a lookup rather than a re-extraction. What matters is choosing names once and keeping them.
Two habits pay for themselves. Use the registered company name rather than a nickname, because the nickname stops being obvious the moment someone new joins. And never encode anything that changes into the name: a tag like Trading Ltd — new bank becomes actively misleading within a year, while Trading Ltd stays true for as long as the company exists.
If entities merge or are sold, resist rewriting history. Keeping the old tag on old rows is what makes a prior-year comparison honest; retagging them to the surviving company makes the comparison look tidy and quietly wrong.
The tags you add yourself
Extraction gives you provenance. The other half of a useful dataset is meaning, and that has to come from you, because no document contains it: a bank statement records that money went to a supplier, never that the cost belongs to a particular project or department.
A small, stable vocabulary works far better than a detailed one. Payroll, rent, utilities, professional fees, bank charges, intercompany — six or eight categories applied consistently answer most questions, while a forty-category scheme is abandoned by the third month. Assign them on recurring descriptions once and they carry forward, because the same supplier tends to appear with the same wording.
These user tags behave exactly like the extracted ones in filters and pivots, which is the point. Our transaction categorisation page goes further into how to build a category set that survives contact with a real ledger.
Pivots that answer real questions
Once entity, period and category are all columns, a pivot table stops being a reporting exercise and becomes the fastest way to answer whatever was just asked. Entity by month gives the group its trend. Category by entity shows where a cost is concentrated. Account by month inside one entity exposes a treasury pattern nobody had noticed.
| Question | Rows / columns | What it shows |
|---|---|---|
| How is the group trending? | Entity × month | Which company moved, and when |
| Where does this cost sit? | Category × entity | Concentration and outliers |
| Is treasury behaving? | Account × month, one entity | Sweeps, idle balances, gaps |
| What changed year on year? | Category × year | Structural shifts, not noise |
| Which rows need review? | Confidence × entity | Where to spend the review time |
One caution worth repeating: use SUBTOTAL rather than SUM in any total row that sits near a filter. A SUM ignores filtering, so a filtered view can show a total that belongs to the whole dataset — the most quietly misleading thing a finance spreadsheet does.
The errors tagging makes visible
A provenance column is also a diagnostic. Several common problems only become visible once you can group by where data came from, and they are the sort that otherwise survive for months.
The same file uploaded twice. Two identical source tags for one period is unambiguous, where the duplicated transactions themselves each look entirely normal.
A missing month. Grouping by entity and period shows gaps immediately. A company with eleven monthly statements instead of twelve is obvious in a pivot and invisible in a list of four thousand rows.
An account nobody mentioned. Groups accumulate accounts, and a tag column is where a forgotten one announces itself — usually as a small entity that appears with three transactions and no owner.
Statements that never proved. Because the balance check is per statement, the failures group by entity, so the review list is bounded and assignable rather than a general instruction to look at everything.
Two exports from one extraction
The export carries the tags in both Excel and CSV, which means the choice between them is about the reader rather than about capability. Excel when a person opens it, because types travel inside the file and nothing gets reinterpreted by a regional setting. CSV when a system imports it, because that is what import routines expect.
The useful discipline is to keep one canonical export and derive everything else from it. A group file plus six separately produced entity files is seven things that can disagree. A group file that six people filter is one thing that cannot.
Where an accounting system supports its own dimensions — tracking categories, departments, classes — the tag column maps to them cleanly on import. Our accounting software export page covers the formats each system expects.
Tagging through the API
For a group that closes on the same cycle every month, the tagging step is exactly the part worth automating first: it is mechanical, it never requires judgement, and doing it by hand is where transcription mistakes enter.
The API returns the same provenance fields in its JSON response, so a pipeline can route each transaction to the right company without a person deciding per file. Statements arriving by email or landing in a shared drive can be converted, tagged and filed automatically, with only the exceptions surfacing for review.
One design note from experience: have the pipeline stop on a failed balance check rather than warn. In an automated run nobody is watching the screen, and a statement that did not prove should never flow onward into a group report on the assumption that someone will notice.
Who benefits most
Anyone whose data has to serve two audiences at once. That is groups with subsidiaries, but also practices handling many clients, property structures with an entity per asset, and single companies with enough accounts that the account itself needs to be a reportable dimension.
Group finance
One close, each entity provable, one consolidated view.
Accountancy practices
Many clients through one process without mixing their data.
Property and SPVs
An entity per asset, dozens of accounts, the same monthly routine.
Anyone facing an audit
Every figure traceable to the page it came from.
What tagging does not do
It records which account money moved through. It does not decide which entity should ultimately bear a cost — when one company pays a supplier on behalf of another, the bank data shows only the payment, and the allocation is a judgement you make and record as your own column.
It is not a replacement for dimensions in your accounting system. Those stay authoritative for reporting; tagging solves the step before, so the import arrives already labelled instead of needing a person to route it.
And it is not storage. The original PDF is deleted immediately after extraction — there is no archive of your statements here, and the tagged data lives in the file you download. Retention of the source documents stays where you keep it today.
Processing runs on EU-hosted infrastructure over TLS and documents are never used to train AI models — the security page has the detail.
See the tags on your own statement
Convert one real statement free — no registration — and look at the columns before deciding anything.