Every figure in the UK Getting Paid Report comes from Adfin's own warehouse: one row per invoice raised for a customer to pay, measured directly. It isn't a survey, a panel or licensed data. This page defines every term the report uses, so you can check a figure or argue with one.
In this article
The short version
- The grain is one payment request: one invoice or fee you raised for one customer to pay.
- Payment method comes from the payment attempts and not your invoice record, so it exists only once the invoice has been paid.
- Direct debit, customer-initiated and imported payments are never blended. Direct debit is 62% of paid invoices and reads 0.20% on time against the due date, purely because of the Bacs cycle (Adfin platform data).
- Late means paid after the due date you set, compared as calendar dates.
- Nothing computed on fewer than 200 payments gets published.
The unit of analysis, and what gets excluded
The unit is the payment request: one invoice or fee you raised for one customer to pay. Receivables reporting often mixes invoice-level and payment-level counts, so if you're comparing these figures with somebody else's, line that up first.
Everything runs against an internal reporting spine with account exclusions already applied, joined and never recomputed, so nothing excluded gets quietly reinstated by a query. About 41 businesses and roughly £1.0 million of lifetime settled value sit outside it.
Four more exclusions: deleted and draft requests, always; voided requests wherever a figure measures collection success, since a cancelled receivable isn't a failed collection; unpaid invoices wherever a figure measures lateness, because lateness needs a payment date; and non-GBP invoices, of which there are none.
Take the third as a bias and not a technicality. The invoices nobody ever paid skew large, so every lateness rate you see understates lateness, most of all at the top of your value range. Figures measuring resolution, like mandate coverage, do include your unpaid invoices.
How payment method is worked out
Your invoice record can't tell you how an invoice was paid: the invoice table has a payment-method column that's empty in every row of this dataset, so it's never used.
Method comes from your payment attempts, each request taking the method of its earliest successful attempt. That join fans out, since retries and part payments give one invoice several payment rows, so it's collapsed back to one row per invoice before counting. Of paid invoices, 1.63% carry more than one successful payment and 0.41% were settled by two genuinely different methods (Adfin platform data). Each counts once, dated by the earliest payment.
The consequence matters more than the mechanics. Method exists only after payment, so "card invoices" means invoices that ended up paid by card and not invoices you offered by card. Every method figure is a segment defined after the fact, and its composition shifts underneath you: direct debit's share of paid invoices roughly doubles over the life of a relationship while the customer-initiated on-time rate inside it falls. That's the relationship-age paradox in the report, and if you take one thing from this page, take it.
Three populations, and why blending them is fatal
Your paid invoices fall into three groups. Add them together and you get a figure that looks authoritative and measures the wrong thing.
| Population | What it is | Share of paid invoices | What its clock measures |
|---|---|---|---|
| Direct debit | Collected by Bacs under a mandate | 62% | The Bacs settlement cycle |
| Customer-initiated | Card, Apple Pay, Google Pay, open banking, bank transfer | 12% | Your customer's decision to act |
| Imported | Paid to you directly, recorded through an accounting connector | 26% | Your accounting system's reconciliation lag |
Adfin platform data, 482,913 paid GBP payment requests over 26 months.
Here's the arithmetic. A direct debit is entered against the mandate a median of two days before the due date and settles five days later, so it lands three days after your due date when nothing has gone wrong, and only 0.20% of collections read as on time against 65.65% of customer-initiated ones (Adfin platform data). With direct debit at 62% of paid invoices, a blended rate is five parts Bacs calendar to one part customer behaviour, reporting the settlement cycle as your customers being late.
So direct debit gets measured on its own terms: first-attempt success, eventual collection, failure rates, retry rates, the time from Bacs entry to money in. Never against your due date. Imported payments are dated by the business's own accounting system, so their lateness levels never appear next to the other two.
Two definitions of late, and where each is used
The reference date is the due date you set on the invoice. Not the invoice date, not a statutory 30-day default, not a date somebody promised you on the phone. On time means the payment landed on or before it, late means after it, and days late is the whole-day difference. Both are calendar dates instead of timestamps, so a payment at 23:00 on your due date counts as on time.
That's what your Adfin dashboard shows you, and it's the conservative measure: an invoice that went overdue and was later paid against a revised date reads as on time. The stricter definition asks whether an invoice was ever overdue at any point. It gives higher lateness, exists only at business-month grain from October 2025, and being a binary flag it can safely span all payment methods. So the tenure figure in the report, 23.01% of invoices overdue in month one falling to 10.15% by month seven, is the one figure computed across every method (Adfin platform data, 43,081 paid invoices, 292 businesses), and you won't see it turned into days.
The due-date correction, and how much it moves
Due dates are stored at midnight UTC for most invoices and at 23:00 the previous evening for about 12% of them, a British Summer Time artefact that read literally would treat your invoice as due a day early. One hour is added before the date is taken, and both versions are published so you can see what that choice is worth:
| Method | Corrected | Uncorrected |
|---|---|---|
| Apple Pay | 72.86% | 72.71% |
| Google Pay | 70.00% | 70.00% |
| Card | 65.13% | 64.49% |
| Open banking | 62.00% | 61.17% |
| Bank transfer | 57.85% | 57.08% |
Adfin platform data, on-time rates for 59,777 paid customer-initiated invoices.
Nothing moves by more than 0.8 percent, so no conclusion you might cite changes. And you can't check a figure you can't reproduce, so the uncorrected column stays.
Maturity gates and censoring
Two figures would be badly wrong without a cohort restriction, and both traps would look to you like findings.
Direct debit reliability uses collections first attempted at least four weeks before the measurement date, because roughly 11,800 Bacs attempts are in flight at any moment and an in-flight attempt isn't a failure. Without that gate, first-attempt success reads 93.74% instead of 96.97% (Adfin platform data). On the matured cohort it holds between 96.9% and 97.0% across six consecutive quarters and 243,038 requests.
Trends drop the two most recent months for the mirror-image reason. Where a population is conditioned on payment, recent invoices still unpaid go missing, so the newest months look excellent: July and August 2026 due months read 70.6% and 82.6% on time against a stable 62% to 66% (Adfin platform data). Both cells clear the publication floor, so they are more dangerous to you and not less. A raw month-of-year table goes out for the same reason, since the calendar's first half carries two years of data and its second half one, so every seasonal claim you read here comes from a fixed panel.
What the warehouse cannot see
Six blind spots, each one ruling out a claim you'll see made elsewhere.
- Chasing. No reminder, escalation or call is recorded, nor its timing, so nothing here tells you which channel or hour works, and the clustering of payments on the due date can't be attributed to a reminder instead of your customer's diary.
- Ledger and payouts. Payout timestamps are incomplete in ways this dataset can't correct and the double-entry ledger is outside it, so no payout-speed or match-rate figure exists.
- Status history. Records carry current status only, so "a mandate was in place" means a record existed before you raised the invoice, active or not, and no churn rate follows.
- Negotiated terms. Terms are inferred from the gap between your invoice date and your due date, and nothing records what you agreed.
- Sector history. A business's vertical is mutable and un-historised, so a reclassification rewrites past splits.
- Bank holidays and local time. Weekday arithmetic runs Monday to Friday with no UK holiday calendar, and timestamps are UTC, so your mid-morning peak is an hour later locally for seven months of the year.
Customer identifiers are scoped to one business too, so the same end customer billed by two accountants appears twice.
What we hold ourselves to when we publish
Five rules, applied before anything reaches a page you read.
- Nothing computed on fewer than 200 payments is published, and every figure states its denominator.
- Nothing is published where one business supplies a large share of the cell, even well above 200. Two of Adfin's verticals are left out of the report on that ground, because a single business supplies roughly half of each.
- No individual business, customer or invoice of yours appears anywhere.
- Rates and ratios are stated exactly. Counts, volumes or pound totals are rounded or left out.
- Restated figures are labelled, so if you're comparing two of our pages you can tell which one is live.
Where to push back
If you're deciding whether to cite any of this, here are the weak points, weak because of what the data is and not how it was queried.
Most differences between groups are composition. Hold the business constant and the on-time gaps between payment methods fall from six or seven percent to under 1.5, while the split between businesses becomes a coin flip.
| Contrast | Pooled gap | Median gap inside one book | Businesses split |
|---|---|---|---|
| Card against Apple Pay | 6.05% | 0.81% | 39 to 32 |
| Card against open banking | 1.51% | 1.44% | 51 to 44 |
| Card against bank transfer | 6.96% | 0.52% | 13 to 13 |
Adfin platform data, on 71 / 96 / 26 businesses with at least 20 payments in both arms.
So read every comparison between groups as a description of who uses what, and not as an effect of the thing being compared. The same goes for invoice size, for sector and for terms.
The population is your biggest caveat: Adfin's own book, weighted towards small accountancy practices billing small recurring fees, median customer-initiated invoice £180, only 1% above £3,250. None of it is a UK national statistic, and the sector comparison describes Adfin's customers and not UK industries.
Common questions
Is this survey data? No. It's Adfin's own warehouse: one row per invoice you raised for a customer to pay, with the payment timestamp, the method and the due date attached. Nothing is modelled, weighted or self-reported.
What counts as paid on time? The payment landed on or before the due date you set, compared as calendar dates, so a payment at 23:00 on the due date is on time. An invoice that went overdue and was later paid against a revised date also reads as on time, which makes it a conservative measure.
Why don't you publish one days-late figure across all payment methods? Because direct debit is 62% of paid invoices and a Bacs collection settles a median of three days after your due date by design, so only 0.20% of them read as on time. A blended figure would mostly measure the Bacs calendar and not your customers.
Why are direct debit figures measured on a matured cohort? Because about 11,800 Bacs attempts are in flight at any moment and an attempt still in the cycle isn't a failure. Restricting to collections first attempted four weeks or more earlier lifts first-attempt success from 93.74% to 96.97%, the figure you can reproduce.
What can this data not tell me? Anything about chasing, since no reminder, call or escalation is recorded. Anything about payouts or cash application. Any mandate churn rate, because only current status exists. And anything causal, since these are observed differences between groups and not experiments.
How often do the figures change? The warehouse syncs several times a day and invoices stay editable, so monthly totals move slightly between reads. Adfin restates the report annually and dates each edition to its snapshot, this one taken at 07:04 UTC on 18 August 2026.
This article describes how Adfin measures payment behaviour in its own platform data and is not legal or financial advice. The figures are observational: they describe one platform's book of mostly small-ticket UK invoices, and no figure establishes cause. Last updated August 2026.
