The Day the Invoice Arrived
Large British companies publish how fast they pay their suppliers twice a year, and the arithmetic is three figures that are all differences between two dates. The Regulations define both dates precisely — and one of them is not the invoice date, not the date you entered it, and not the date it was due.
There is a statutory report in the United Kingdom that is unusually easy to underestimate, because it looks like something you could assemble from a spreadsheet in an afternoon. A qualifying company publishes, twice a financial year, how long it takes to pay its suppliers. Average days. Percentage inside thirty days, inside sixty, beyond. Percentage of what fell due that was paid late.
Four numbers. All of them differences between two dates. And the whole difficulty of the report is that the Regulations define those two dates, and neither definition is the field your purchasing system is most likely to be holding.
The shape of the obligation, briefly
A qualifying company has two reporting periods in a financial year: the first six months, and the remainder. If its accounting reference date moves so that the year runs nine months or less, there is one period; if it runs more than fifteen months, there are three. Each report is published on a government web service within the filing period, which is thirty days beginning with the day after the reporting period ends.
Whether the duty reaches a particular company is a Companies Act question — it turns on exceeding two or all three of the medium-sized thresholds on both of the relevant balance sheet dates, and for a parent company on the group thresholds as well. We have deliberately not printed those figures anywhere on this page, because they live in a different Act which we did not read for this article, and because the Regulations themselves contain a rule for what happens when they are amended. That is your accountants' determination and it is not a close call for us to make.
Two definitions, and they decide every figure in the report
This is the part worth reading twice. Schedule 1 defines the terms it uses, and the definitions are narrower and more operational than the plain words suggest.
What the Regulations mean by four ordinary phrases
The phrase The definition, and what it rules out
Relevant day The day the clock starts
The day the company receives an invoice, or otherwise has notice of an amount for payment. Not the date printed on the invoice. Not the date it reached your accounts system. Day 1 is the day after it.
Payment period The window you agreed
The period in which the company is contractually required to pay. A term from an agreement, not a default and not a habit — and where you have no standard terms, the report uses your most frequently used ones instead.
Falls due The deadline
The last day of the payment period. So the late-payment percentage is measured against a date derived from a contract term, on invoices grouped by when that date fell rather than by when they arrived.
Made The day the clock stops
When the payment is received by the supplier — or, under a supply-chain finance arrangement, when the finance provider receives it from you. Not when you approved it, and not when it left your account.
And one more, which is the most human line in the instrument: where receipt is delayed for a reason the company is not responsible for, the payment is deemed to have been made when it would have been received without that delay.
Start the clock when the invoice arrives, stop it when the supplier has the money, and measure both against a term somebody agreed. Three facts, and most purchasing systems hold none of them.
Our purchase side, measured against those definitions
We should be specific rather than general here, because "we do this" and "we do not do this" are both too coarse.
What each figure needs, and what a purchase order in our system holds
| The input | Held as a value | Reportable across orders |
|---|---|---|
| The day the supplier's invoice was received | No | No |
| The agreed payment period, in days | No | No |
| The day the order was raised | Yes | Yes |
| The expected delivery lead time | Yes | Yes |
| The amount, what has been paid, what is outstanding | Yes | Yes |
| The day the money left, per payment, with its rail and reference | Yes | Yes |
| The day the supplier was credited, as the provider reported it | Partly — configurable by you | No |
| Whether an invoice was held back because of a dispute | No | No |
Built and maintained Configurable by you, not maintained by us Not built
The two "no" rows at the top are the two dates the Regulations start and stop the clock between. Everything below them is real, useful and about something else.
There is no payment term anywhere in this product — not on a vendor, not on an order, and not on a contract, because there is no contract entity on the buying side at all. The supplier's own invoice is held as a link on the order rather than as a record with dates on it. So the day it arrived, and the number of days you agreed to pay within, are both facts the system has never been asked for.
And what our payables ageing is actually ageing
This one is worth saying plainly because the report is named in a way that invites the wrong reading. Our payables ageing buckets each open order by comparing today against the order date plus the delivery lead time — the number of days you expected the goods to take. Not a payment term, because there is not one to use. So an order placed with a fourteen-day lead time and sixty-day terms appears in the overdue buckets forty-six days before any money is owed. The code says as much in its own comment, and the screen says "Payables aging", and those two things are not the same claim. It is now in our public gaps file with the fix beside it.
One more, and it is the subtler half. When a payment goes out on a mobile-money rail and the provider confirms it, we mark the transaction successful and record the settlement moment — as our own clock at the instant we processed the confirmation, inside the record's own detail rather than as a column of its own. For a rail that settles in seconds the difference is immaterial. What matters for a report like this one is that the figure is ours rather than the provider's, and that nothing can add it up across ten thousand payments.
The report has gained columns twice, and it expires
A detail that matters more than it sounds if your process for this is a spreadsheet somebody inherited. In April 2024 the required contents grew: the three percentage bands acquired a value total each, the late-payment percentage acquired a value total, and a new figure arrived — the percentage of payments falling due that were not paid within the payment period as a result of a dispute. Then for financial years beginning on or after 1 April 2025 a second schedule was added, covering construction contracts and their retention clauses.
So a working method built in 2023 produces a report that is missing three required statements, and a working method built in 2024 is missing a schedule. Nothing about your own data changed. The list of things you have to say about it did. And the Regulations themselves cease to have effect in April 2031, which is a reminder that the whole regime has a stated end date rather than being a permanent feature of the landscape.
The figure that is not arithmetic at all
Schedule 1 finishes with the name of the director who approved paragraphs 2 to 11. Everything above it — the terms, the dispute process, the finance arrangement, the averages, the bands, the late percentages — is approved by a named person, and their name is part of the published report.
That changes what a software vendor should be offering. A figure a director signs for cannot be produced from an approximation that nobody flagged. Which is the real reason we would rather write the paragraph above about our ageing report than let somebody discover it in a filing.
The short version
Before you ask whether a system can produce this report, ask it three questions about dates. When did the invoice arrive — not the date on it, the day it reached you. How many days had you agreed to pay within, as a term on that relationship rather than a habit. And when was the supplier actually credited. If the answers are "we infer it", "we do not store one" and "when we recorded the payment", then no amount of reporting will fix it, because the report is a subtraction and two of the three operands are missing. Ours holds the third, ages payables against a delivery lead time in the absence of the second, and says so on this page rather than in a footnote.
What AWRA OpsHub does today
- Every payment to a supplier in one register, with the rail, the reference, the amount, the status and the order it settles — and posted back to that order, so what has been paid and what is outstanding move together.
- Vendor spend for any date range grouped by supplier, with the order count, the total, the amount paid and the balance due, exportable to a spreadsheet or a PDF.
- Payables ageing in buckets, with the currency it is denominated in stated on the report rather than left to be assumed.
- The supplier's own invoice reachable from the order, so the document behind a figure is one click away.
- Mobile-money and card rails that confirm themselves, so a payment's status comes from the provider rather than from somebody remembering to tick it.
More we can add to your workspace
- A payment term on the supplier or the order, expressed in days, so a due date is the day money is owed rather than the day goods were expected — and so payables ageing measures the thing its name implies.
- The day a supplier's invoice was received, held separately from the date printed on it and the date it was entered, because that is the day every figure in this report counts from.
- Days-to-pay as a measure, with the arithmetic mean and the share of payments landing inside each of the three bands, over any period.
- The moment the supplier was credited, as the provider reported it, held as a column of its own so it can be summed, sorted and averaged.
- A dispute marker on a payable, so an invoice deliberately held back is separable from one that was simply slow — which is a required figure in its own right since 2024.
- A contract on the buying side, which is where a payment term, a maximum period and a dispute process would properly live rather than being repeated on every order.
Where we point you to a specialist
- We will not tell you whether you are a qualifying company. The test runs through the medium-sized thresholds in the Companies Act 2006, applied on both of the relevant balance sheet dates, with an additional group test for a parent — and the Regulations carry their own rule for what happens when those thresholds are amended. Your accountants own that answer, and we have deliberately kept the figures off this page rather than repeat numbers we have not read at source.
- We will not compute a figure a director has to put their name to out of an input we know is approximate. Two of the three dates this report subtracts are ones our purchase side would have to start capturing, and a system that filled them in by inference would be manufacturing a signed statement. Build the fields first, then the report. That order is not a preference.
The first two items are a column each, a form field each and a change to one query, and between them they turn payables ageing from a delivery measure into a payment one. The third follows from them for free. The last is the one worth arguing about before anybody starts: a term that belongs to a relationship rather than to a document wants a contract to live on, and adding one properly is a smaller piece of work than maintaining the same number on nine hundred orders.
What we can build for the United Kingdom on top of the standard product
Everything listed above as something we can add describes what ships in the standard product today — it is a starting point for the United Kingdom, not a limit on what AWRA OpsHub can do there. Kenya's eTIMS integration and its maintained payroll engine are in the product because Kenyan clients needed them and commissioned them; neither appeared by itself. The same door is open here. If tax on the purchase side, a nine-box VAT return, transmission to HMRC, a bank or mobile money feed, a statutory return format, a rule specific to how your operation runs, or a link to a system you already have is what stands between you and a decision, tell us and we will scope it as a build — written spec, timeline and price — before you commit to anything.
The three builds, and they only work in this order
Tax on the purchase side first: a rate and a tax type held against a purchase order and an expense, not just an amount, because an amount with no rate cannot tell a recoverable input from a blocked one. Then a VAT return assembled from it — the sales-side boxes are already answerable from data we hold, and it is the input-tax boxes that need the schema change underneath them. Only then transmission through HMRC's interface under Making Tax Digital, with the authorisation and testing that requires. Quoted in that order because the reverse order is how vendors end up with a filing button over figures nobody can trace, and the digital-link rule is precisely a rule about traceability.
Banks and payments
Faster Payments, Bacs direct debits and Open Banking statement feeds wired into the Payments Register, so money in and out reconciles against the documents rather than being re-keyed from a bank screen.
The operational work, which is what most commissions actually are
An extra approval stage in a chain that does not match the standard one, a custom field set on employees or assets that only your sector needs, an expiry that has to block an order rather than send an email, a report your board asks for in a shape nothing produces, or a scanner or weighbridge feeding the goods-in door. These are the commissions we are asked for most often and the smallest ones we quote — and unlike a revenue-authority pipeline, none of them waits on a regulator.
Payroll and statutory returns
A UK payroll engine with PAYE tables, National Insurance, Real Time Information submissions and pension auto-enrolment assessment computed on live employee records. None of it exists today; labour cost attribution to projects and cost centres does.
Systems you already run
The accounting package, CRM, online store or custom database you intend to keep — connected through our API so a fact is entered once and appears everywhere it is needed.
How it works: you describe the requirement, we return a written scope, timeline and cost, and once agreed it is built into your environment and maintained as part of the product. No roadmap slide, and no pretending in a demo that something exists when it does not.
Tell us what you need integratedThree questions, and they are all about dates
Where do you store the day a supplier's invoice reached us?
What you will probably hear
The invoice date, or the date it was entered, offered as the same thing.
How to read it
They are three different days and the Regulations name the third. Ask to see the field. If the answer is the created-at stamp on a record, the measure will drift with how quickly the finance team keys things in, which is the one variable the report is not supposed to be about.
Is a payment term a field on the supplier, or a habit?
What you will probably hear
A default number of days configured somewhere global.
How to read it
A global default cannot express a term you negotiated with one supplier, and the report asks for the maximum period in any contract you entered into during the period. Ask whether the term can differ per relationship and whether a change to it is recorded with a date.
When does your system consider a payment made?
What you will probably hear
When it was recorded, or when the batch was released.
How to read it
The Regulations say when the supplier received it. That is a fact about somebody else's bank, so nobody can compute it — they can only capture what the rail reported. Ask whether that timestamp is stored as a field you can average, or buried in a payload.
See the procurement and payments side
Purchase orders with delivery and payment status, every supplier payment in one register with its rail and reference, vendor spend for any period, and payables ageing with its currency stated.
Explore procurementFrequently asked questions
Can your system produce this report?
No, and the reason is arithmetic rather than reporting. Every figure in it is the number of days between the day an invoice was received and the day the supplier was credited, judged against a contractually agreed payment period. We hold none of those three today: there is no payment term field anywhere in the product, no date-received on a supplier invoice — it is held as a link on the order rather than a record — and the settlement moment we capture is our own clock at the point a rail confirmed, kept inside the payment's detail rather than as a field. Adding the first two is a small piece of work and it has to come before any report.
What is your payables ageing measuring, then?
The delivery lead time. Each open order is bucketed by comparing today against the order date plus the number of days the goods were expected to take, because there is no payment term to use instead. That means an order with a short lead time and long payment terms shows as overdue well before any money is owed. It is a genuinely useful operational view of orders running late, and it is not a measure of paying suppliers late. We have written it into our public gaps file with the fix beside it rather than leaving the report's name to imply the stronger claim.
Why does the day the invoice arrived matter so much?
Because it is where the Regulations start the clock: the relevant day is the day the company receives an invoice or otherwise has notice of an amount for payment, and day one is the day after. If a system uses the date printed on the invoice instead, the measure improves whenever a supplier dates something early and worsens whenever they date it late — neither of which is about you. If it uses the date the invoice was keyed in, the measure tracks how fast your finance team opens post. The published figure is supposed to be about your payment behaviour, and only the received date isolates that.
Has the required content changed recently?
Twice. From April 2024 the three percentage bands each gained a value total, the late-payment percentage gained a value total, and a new figure was added: the percentage of payments falling due that were not paid within the payment period as a result of a dispute. Then for financial years beginning on or after 1 April 2025 a second schedule was added for qualifying construction contracts, covering retention clauses. A method built before either change produces a report that is short of required statements, and nothing in your own data will tell you.
Does this apply to us if we are not a UK company?
We are not going to answer that. The duty attaches to a qualifying company as defined in regulation 5, which runs through the medium-sized thresholds in the Companies Act 2006 applied across two balance sheet dates, with a group test for parent companies, and a separate instrument modifies the Regulations for limited liability partnerships. We read the 2017 Regulations and their amendments and stopped there deliberately. Whether the duty reaches your group is a question for your accountants and your counsel.
