One statement, two countries
A British bank statement is not an American one with a different currency symbol in front of the numbers. The layout rhymes — dates down the left, a description, a debit column, a credit column, a running balance — and almost everything else belongs to a different banking system. Read it as though it were American and the arithmetic still adds up perfectly, on the wrong month’s transactions.
- 05/09 is not a date until you know the country
- Miss the acquirers and every burden ratio reads high
- A bounced payment has a different name in each country
The ambiguity that deletes revenue quietly
Start with the failure that is hardest to notice. A numeric date like 25/09 can only be read one way: there is no twenty-fifth month, so the document is writing day first. A date like 05/09 can be read both ways, and the two readings are four months apart.
The tempting rule is to swap the fields whenever the first one is greater than twelve. It rescues 25/09 and it fails on 05/09, and the failure has a particular shape: on a British statement the days from the 13th onward land in the right month, while the 1st through the 12th scatter across eleven wrong ones. What happens next is worse than a mess. Every analysis clamps transactions to the statement period, so the scattered rows fall outside it and are dropped — and the report comes out clean, well formed, internally consistent, and missing roughly the share of the month that falls on or before the 12th.
Nothing downstream catches it. The reconciliation check that normally protects a file — opening balance plus credits minus debits equals the closing balance — sums an unordered set. It holds exactly as well when the dates are wrong as when they are right. A missing third of a merchant’s revenue produces a report that passes every test it is given.
The only defence is to stop deciding row by row. The convention is settled once for the whole document, from the tokens that can only be read one way, and then applied to every row including the ambiguous ones. Dates that work either way carry no information and are ignored rather than assumed. And when a document contradicts itself — printing both 25/09 and 09/25 — nothing is settled and nothing is guessed, because guessing is what caused the damage in the first place.
Four things a country tells you about a line of text
Once the statement has a country, a dozen readings change with it. These are the four that move numbers.
The rails are named differently, and the names are noise
American statements say ACH, CCD, PPD, WEB. British ones say Direct Debit, Faster Payment, BACS, CHAPS, Standing Order. None of these words say who was paid — they name the channel — so they have to be treated as noise when grouping payments by counterparty. The catch is that in Britain the noise words include DEBIT and PAYMENT themselves, which are perfectly good identity words on an American statement.
The card acquirers are a different set entirely
A British merchant’s takings arrive as settlements from Worldpay, Dojo, SumUp, Zettle, Takepayments, Paymentsense, DNA Payments, Teya, or a delivery platform like Just Eat or Deliveroo — names that mean nothing to a US-trained reader. Miss them and they are not counted as revenue, the denominator deflates, and every burden ratio reads high on a merchant who is doing fine.
The tax collector has a different name and different words
The IRS, EFTPS and a state department of revenue on one side; HMRC, VAT, PAYE and Corporation Tax on the other. These are not interchangeable strings: "sales tax" does not match VAT, and a UK collection often arrives as a Direct Debit under an accounting-office suffix rather than a name anyone would recognise.
A bounced payment has a different name
An American statement bounces an item as NSF. A British bank prints "unpaid". Both mean the account could not cover what was presented, and both belong in the same place in a report — but a report that says NSF to a British funder is using a term they have never once seen on a statement.
A country is a row, not a special case
The obvious way to add a second country is to add conditions: if the currency is pounds, also check these words; if the currency is pounds, read the dates the other way round. That works exactly once. The second time, the country facts are spread across every module that needed one, several of them keeping their own copy of the same list, and a third country means editing all of them.
So the country is resolved once per statement and its facts are data — one row per country, holding the rail words, the descriptor prefixes, the legal forms every company carries, the tax authorities, the acquirers whose settlements are the merchant’s own takings, the date convention, and the word that country uses for a bounced item. Readers that know their statement’s country ask for its row. Readers that classify a description without one take the union across countries, so a British rail word is noise on any statement and an American tax authority is a tax payment anywhere. Adding a country is adding a row.
Money scale stays with the currency rather than the country, because a threshold in pounds is a property of the unit, and a country simply names its unit.
What the statement has to tell us first
All of this rests on one fact the statement itself carries: its currency, settled from the marks printed on the page. Currency names the country, the country names the row, the row names everything else.
When the page does not make its currency readable, the country is not known — it is assumed, and the assumption is recorded as an assumption rather than hardening into a fact nobody declared. That is the same principle the rest of the report runs on: a figure derived from an assumption should always be traceable back to it.
For a funder writing on both sides of the Atlantic, the practical effect is narrow and worth having. A transaction lands in the month it actually happened. Card settlements count as takings, so burden is measured against the revenue the business really earned. And the report uses the words that appear on the statement in front of you, not a translation of them.
Common questions
Does MetrikData read UK bank statements?
Yes. Sterling statements are read with day-first dates, UK payment rails, UK card acquirers and delivery platforms counted as takings, HMRC collections recognised as tax, and bounced items reported with the word a UK bank actually prints.
How is the date format decided?
From the document itself. Dates that can only be read one way — a field above twelve cannot be a month — settle the convention for the whole statement, which is then applied to every row, including the ones that would read validly either way.
What happens if no date in the statement proves the order?
The country’s own convention is used, which is the right prior when there is no evidence against it. What is never done is deciding row by row, because that is exactly what scatters the first twelve days of a month across eleven other months.
Why do UK card acquirers matter so much to the numbers?
Because for most retail and hospitality merchants the acquirer settlement is the revenue. If those credits are not recognised as takings they drop out of the denominator, and the burden percentage — financing payments against revenue — reads far worse than the business deserves.
Can other countries be added?
The shape is built for it: a country is one row of facts rather than a set of conditions scattered through the code. What each new country needs is its own vocabulary — rails, acquirers, tax authorities — and statements to check it against.
Related
Read a statement in the language it was written in
Upload a file in dollars or in pounds and see the positions, the cadence, and the burden from the transactions themselves.