When payments carry contract identity, quarterly transparency becomes routine.
On 29 July 2026 the first quarterly contract payment information is due on the UK central digital platform. The teams that will find it easy are the ones whose payment records already know which contract they belong to, and the fix that gets them there improves cash visibility and supplier trust well beyond the disclosure.
Thesis
A payment that knows its contract answers the question by itself.
Most finance systems give a payment two identities. It belongs to a supplier, and it belongs to a set of general ledger accounts. Section 70 asks for a third: the contract under which the cost was incurred. The Cabinet Office guidance describes the purpose directly, as linking payments to the specific public contract under which the cost was incurred, so that procurement and financial data align.
That is a genuinely useful alignment, and it is worth separating from the compliance framing. An organisation that can attribute disbursements to contracts can answer questions it previously estimated: how much of this contract has been drawn down, which suppliers are paid under which agreements, whether spend is tracking the award. The guidance makes the same point, noting that aligning procurement and financial data makes it easier to spot inconsistencies, prevent errors, provide accurate reconciliation and respond to enquiries.
The engineering is modest and the timing is favourable. The obligation attaches only to procurements commenced on or after 1 April 2026, and the guidance itself observes that authorities may have little or no contract payment information to publish in the first quarter. A quiet first cycle is the best possible conditions in which to prove an extract works.
Where the rules stand, and why operators should care.
Section 70 has been live since 1 April 2026
Section 70 of the Procurement Act 2023 requires a contracting authority to publish specified information about payments of more than £30,000 (including VAT) made under public contracts. The Cabinet Office guidance confirms it applies to public contracts procured under the Act in accordance with a procurement procedure that commenced on or after 1 April 2026, the date section 70 was brought into force.
The obligation is already running. What makes it tractable is that it attaches to new procurements, so the in-scope population grows from a known start date rather than arriving as a historic backlog.
The first publication is due by 29 July 2026
Section 70(5) defines the reporting period as a period of three months ending with 31 March, 30 June, 30 September or 31 December. Information must be published on the central digital platform within 30 calendar days of the end of each quarter, with the 30-day period beginning with the last day of the quarter. The guidance states the first publication is therefore due by 29 July 2026 for the period 1 April to 30 June 2026.
The first cycle is deliberately gentle. The guidance itself notes authorities may have little or no contract payment information to publish in that first quarter, which makes it an unusually low-risk quarter in which to prove the extract end to end.
The threshold and the published figure use different VAT bases
The guidance is explicit: for the purposes of meeting the £30,000 limit, payments are valued inclusive of VAT, but the amount to be published is exclusive of VAT, whether recoverable or not. If an individual payment is more than £30,000 including VAT but falls below £30,000 once net of VAT, the specified information must still be published.
This is a two-field problem, not a one-field problem. A payment record needs a gross value for the in-scope test and a net value for the disclosure, computed by the same logic every quarter rather than by whoever builds the extract.
The unit of measurement is the individual payment, per contract
There is no requirement to group payments of £30,000 and below made under a single contract over the quarter. The guidance gives the example of twelve monthly payments of £20,000 including VAT under one public contract, which do not become publishable even though they exceed £30,000 collectively.
The rule rewards precision rather than volume. Aggregate spend per supplier, the number most AP reports lead with, is not the measure that determines disclosure.
Combining invoices into one payment can create the obligation
It is the sum of money paid in respect of an individual public contract at any one time that determines whether the payment is in scope. The guidance states that where several invoices for £30,000 or below, which would not individually trigger publication, are combined into a single payment that takes the amount over the threshold, information about that payment must be published.
Payment-run grouping policy is now a disclosure design decision. The same invoices, settled the same week, produce a different public footprint depending on how the proposal batched them.
A payment spanning two contracts is split, not totalled
Where payments to the same supplier under multiple in-scope contracts are combined, the obligation is triggered only if the £30,000 threshold is exceeded for a single contract. The guidance works through two payments of £20,000 relating to two separate contracts, totalling £40,000, which require no publication; and a case where £40,000 relates to contract A and £20,000 to contract B, where only the contract A amount is reported.
The guidance goes on to say authorities should consider whether internal systems allow accurate reporting in those circumstances, or whether payments to different contracts should be separated. That is the clearest statement of the underlying data requirement anywhere in the document.
The mandatory fields are identifiers, not descriptions
Regulation 38A of the Procurement Regulations 2024, inserted by the Procurement (Amendment) Regulations 2026, requires the name, contact postal and email address and unique identifier of the contracting authority which made the payment, and of the authority which published the contract details notice under section 53 if different; the unique identifier for the procurement; the unique identifier for the contract to which the payment relates; the name and unique identifier of the supplier paid; the value of the payment net of VAT; and the date the payment was made.
In practice the guidance names these as the PPON for the authority, the OCID for the contracting process, a contract identifier, and the supplier unique identifier. All four are external keys. None of them originate inside the finance system.
Internal reference numbers do not perform the match
Authorities may add optional information, including an internal payment identifier that distinguishes multiple payments made on the same date to the same supplier, and a procurement reference number allocated by their own organisation. The guidance states plainly that these identifiers will not be used to match a payment to the information published in notices, and the mandatory identifiers are still required.
A local reference is useful for answering a question about a specific line later. It is not a substitute for holding the platform identifiers on the record.
Publication is a bulk upload that can be assembled progressively
Information for all in-scope payments in a quarter can be uploaded to the central digital platform as a single spreadsheet through the authority buyer view dashboard. Authorities can upload multiple times before submitting, so an organisation could upload monthly and submit the full report at the end of the quarter, with multiple users collaborating on review and validation.
That converts the deliverable from a quarter-end scramble into a monthly rhythm with a quarterly submission, which is how every other recurring finance disclosure is best run.
Section 70 sits alongside the payment obligations already in force
Section 68(2) implies a term into public contracts that sums due are paid before the end of the period of 30 days beginning with the day on which an invoice is received. Section 69 requires a payments compliance notice, published within 30 days of the end of a six-month reporting period, setting out the extent of compliance with that term, including the average number of days taken to make payments.
Both measures start from the invoice receipt date. An ERP that records only a posting date or a document date cannot evidence either one accurately, and the two obligations reward the same single fix.
The threshold rules reward a precise payment record.
Three details in the guidance decide most of the implementation, and each of them is specific enough to encode. The threshold is tested on the individual payment, valued inclusive of VAT. The figure that gets published is the same payment net of VAT. And the test is applied per contract, not per supplier and not per quarter.
The combination produces a result that surprises people the first time they see it. A payment of more than £30,000 including VAT is publishable even if the net amount falls below £30,000, and the guidance says so explicitly. Twelve monthly payments of £20,000 including VAT under one contract are not publishable at all, despite totalling £240,000 across the year.
The most operationally interesting rule is the one about combination. Because it is the sum paid in respect of an individual contract at any one time that determines scope, merging several sub-threshold invoices into one settlement can create a publishable payment. This makes the payment proposal a reporting-relevant control, which is not how most AP teams currently think about batching rules.
Where a single payment spans two contracts, the guidance is equally precise: test each contract separately, and report only the amount relating to the contract that crossed the threshold. It then advises authorities to consider whether their internal systems allow accurate reporting in those circumstances, or whether payments to different contracts should be separated. Read as a system requirement, that sentence is the whole article.
Contract identity on the payable line
Carry a contract reference from the contract register through the purchase order, the invoice, and the payment line, so a payment can always be attributed to one contract without inference. This is the field that the whole obligation turns on.
Evidence to retain
Contract identifier, procurement identifier (OCID), contract details notice reference, in-scope flag, procurement commencement date, awarding authority PPON, paying authority PPON.
Platform identifiers on the supplier master
Store the supplier unique identifier issued by the central digital platform on the vendor record itself, alongside the internal vendor number, rather than resolving it at extract time from a name match.
Evidence to retain
Vendor number, supplier unique identifier, legal name as registered, registration date, identifier source, last verified date, verifier.
Dual-basis payment valuation
Compute and store both the gross value that decides the in-scope test and the net value that gets published, on the payment record, so the two never drift apart between quarters or between analysts.
Evidence to retain
Payment reference, gross value including VAT, net value excluding VAT, VAT amount, VAT recoverable flag, currency, threshold test result, test version.
Data Model
External identifiers belong on the master record.
Every mandatory field in regulation 38A other than the amount and the date is an identifier, and none of them are generated inside the finance system. The PPON belongs to the contracting authority, the OCID to the contracting process, the contract identifier to the published notice, and the supplier unique identifier to the supplier record on the platform. They arrive at award and they should be written to the contract and vendor masters at that moment.
The guidance closes the obvious shortcut. Authorities may add an internal payment identifier and their own procurement reference number as optional information, and both are useful for answering a later question about a specific line. But the guidance states that these will not be used to match a payment to the information published in notices, and the mandatory identifiers are still required. A local reference does not stand in for a platform key.
There is one defined relief worth knowing rather than relying on. Regulation 38A does not require the contract and procurement identifiers where no notice relating to the contract has previously been published on the platform and an identifier is not available. That is a narrow allowance for a genuine gap, not a general tolerance for master data that was never captured.
The last field is the one with the widest benefit. Recording when an invoice was actually received, separately from its document date and its posting date, is what makes both the section 68 payment term and the section 69 average-days-to-pay measure computable rather than estimated. It is a small change that pays into two obligations and into every supplier conversation about payment performance.
Payment-to-contract allocation that survives aggregation
Where a single disbursement settles invoices across more than one contract, retain the contract-level split on the payment, not only on the invoices behind it. The reporting rule tests and reports per contract.
Evidence to retain
Payment reference, contract identifier, allocated gross amount, allocated net amount, constituent invoice references, allocation method, allocation timestamp.
Invoice receipt as a first-class timestamp
Record when an invoice was actually received, distinctly from the supplier invoice date and the accounting posting date, because both the 30-day payment term and the average-days-to-pay measure begin there.
Evidence to retain
Invoice reference, receipt timestamp, receipt channel, invoice date, valid-invoice determination date, dispute raised date, dispute resolved date, payment date, days elapsed.
Disclosure and redaction register
Keep a record of what was published each quarter, and of any decision to withhold information, with the reason. The guidance requires an authority relying on section 94 to publish that information is withheld and explain why, unless it is satisfied that doing so would be contrary to the interests of national security.
Evidence to retain
Reporting period, submission date, payment count, withheld flag, withholding basis, published explanation, approver, review date, prior-notice redaction cross-reference.
Run it as a monthly rhythm with a quarterly submission.
The platform mechanics are more generous than the deadline suggests. All in-scope payments for a quarter can be uploaded as a single spreadsheet through the authority buyer view dashboard, authorities can upload multiple times before submitting, and the guidance explicitly contemplates uploading monthly and submitting the full report at the end of the quarter. Multiple users within the organisation can collaborate on preparing, reviewing and validating each report.
Designed that way, the quarterly deadline becomes a review step. The month-one upload exposes missing supplier identifiers and unattributed payments while there is still a full quarter to correct the underlying master data, which is precisely when correcting it is cheap.
The reconciliation is the control worth building deliberately. Compare the extract to the payments subledger for the period and account for every in-scope payment that did not reach the file. The guidance is clear that it is the responsibility of the contracting authority making the payment to publish on time and complete, and that failure to publish when required, or publishing incorrect or incomplete information, could result in non-compliance with the Act.
Redaction deserves its own small process. Where information is withheld under section 94, the authority must publish that information is withheld and explain why, unless satisfied that doing so would be contrary to the interests of national security. The guidance also makes clear that a decision is taken case by case at the time of publication, and that an authority cannot simply withhold information because it was withheld in an earlier notice.
Implementation checklist
1. Fix the in-scope population from the procurement start date
Tag public contracts whose procurement procedure commenced on or after 1 April 2026 in the contract register. Everything procured under the previous regime, or under a procedure commenced earlier, sits outside the duty even if the contract was awarded later.
2. Pull the platform identifiers once, at award
Capture the OCID, the contract identifier, the paying and awarding authority PPONs, and the supplier unique identifier when the contract details notice is published, and write them to the contract and vendor records then. Retrieving them each quarter is the step that will not scale.
3. Make the payment run carry the contract split
Ensure the payment proposal preserves contract-level allocation when it batches invoices, and that the remittance advice reflects it. Where a single payment settles two contracts, the split has to exist before the extract runs, not be reconstructed from it.
4. Implement the threshold test as code, on the gross value
Test each individual payment, per contract, against £30,000 including VAT, then publish the net figure. Keep the test in one place so the same rule produces the same population in every period.
5. Run the extract monthly and submit quarterly
Use the platform ability to upload multiple times before submission. A monthly upload turns the quarterly deadline into a review rather than a build, and surfaces missing identifiers while there is still time to fix the master data.
6. Reconcile the published set against the ledger before submitting
Compare the extract to the payments subledger for the quarter and explain every in-scope payment that did not make the file. Failure to publish when required, or publishing incorrect or incomplete information, could result in non-compliance with the Act.
Suppliers gain a public record worth reconciling.
The obligation falls on contracting authorities, but the output is a searchable public record of what an authority says it paid, to whom, against which contract, and on what date. For a supplier to the UK public sector, that is a new external confirmation of cash applied, available quarterly and at no cost.
The useful discipline is to treat it as a reconciliation source rather than a publication to read. Matching published payment lines against the sales ledger surfaces the ordinary frictions of collections work: a payment recorded against a different contract, a remittance that never arrived, a settlement date that differs from the date cash landed. Each of those is easier to raise with a date and a contract identifier attached.
Commentators on the supplier side, including Crowell & Moring, note that isolated large payments can be read without commercial context, and that the transparency notices taken together create a public performance profile. The constructive response is preparation rather than concern: know what your own ledger says before the quarter publishes, and be ready to explain a milestone payment as a milestone.
There is a master data consequence for suppliers too. Registration on the central digital platform produces a unique supplier identifier, and that identifier is now the key that links published payments to the organisation. It belongs on the customer record in the supplier's own system, next to the entity that issues the invoices.
Example contract payment evidence payload
{
"payment_reference": "pay_2026q2_004412",
"payment_date": "2026-06-18",
"paying_authority_ppon": "PXXX-XXXX-XXXX",
"supplier": {
"vendor_number": "V-10442",
"supplier_unique_identifier": "PXXX-XXXX-YYYY",
"identifier_source": "central_digital_platform",
"last_verified_on": "2026-04-02"
},
"contract_allocations": [
{
"contract_identifier": "C-2026-0187",
"procurement_ocid": "ocds-xxxxxx-0187",
"procurement_commenced_on": "2026-04-14",
"in_scope_section_70": true,
"gross_amount_incl_vat": 42000.00,
"net_amount_excl_vat": 35000.00,
"threshold_test": "gross_gt_30000",
"publishable": true,
"constituent_invoices": ["INV-88213", "INV-88240"]
},
{
"contract_identifier": "C-2026-0203",
"procurement_ocid": "ocds-xxxxxx-0203",
"procurement_commenced_on": "2026-05-06",
"in_scope_section_70": true,
"gross_amount_incl_vat": 20000.00,
"net_amount_excl_vat": 16666.67,
"threshold_test": "gross_lte_30000",
"publishable": false,
"constituent_invoices": ["INV-88301"]
}
],
"payment_terms_evidence": {
"earliest_invoice_received_on": "2026-05-27",
"days_to_pay": 22,
"within_section_68_term": true
},
"disclosure": {
"reporting_period": "2026-04-01/2026-06-30",
"submitted_on": "2026-07-21",
"lines_published": 1,
"withheld": false
}
}Constructive failure modes to design around.
Contract identity lives only on the purchase order
Push the contract reference down to the payable and the payment line. Systems that hold it at PO level alone lose it exactly where the disclosure needs it, at the point of disbursement.
Supplier identifiers are resolved by name matching
Store the platform supplier identifier on the vendor master and verify it. Name matching against a public register works until a trading name, a merger, or a punctuation difference makes it quietly wrong.
The VAT basis is applied consistently but incorrectly
Encode both bases explicitly. Using the net figure for the threshold test understates the population, and publishing the gross figure overstates every line. The guidance calls for gross to test and net to publish.
Payment batching is treated as a purely operational choice
Review how the payment proposal groups invoices, with the disclosure consequence in view. Combining invoices can create a publishable payment that separate settlements would not have produced.
Redaction is inherited from an earlier notice
Assess withholding at the time of publication. The guidance states an authority cannot simply withhold information because it was withheld in an earlier notice; the section 94 requirements must be met in respect of the information being withheld now.
Missing identifiers are discovered at the deadline
Validate identifier completeness monthly. Regulation 38A does allow the contract and procurement identifiers to be omitted where no notice relating to the contract has previously been published on the platform and an identifier is not available, but that is a defined exception rather than a fallback for incomplete master data.
API and event-design considerations.
A payables layer that supports this cleanly should expose events such as contract.registered, identifiers.captured, invoice.received, payment.proposed, payment.allocated, disclosure.extracted, and disclosure.submitted.
Each should carry the contract identifier, the procurement identifier, the supplier identifier, gross and net amounts, the payment date, an actor, and an idempotency key. The case to design for explicitly is the re-run: a quarterly extract regenerated after a correction must produce a deterministic result and preserve what was previously submitted, because the prior submission is a published fact that may need to be reproduced later.
The wider prize is not the file. It is a payments subledger in which every disbursement carries a contract dimension. Once that exists, contract drawdown, supplier concentration by agreement, and payment performance by contract all become queries against data the organisation already has.
What is out of scope
Section 70(4) excludes a utilities contract awarded by a private utility, a concession contract, a contract awarded by a school, and contracts awarded by a transferred Northern Ireland authority except where awarded as part of a reserved procurement arrangement or devolved Welsh procurement arrangement. The guidance adds that section 70 does not apply to the establishment of framework agreements, under which no payments are made, nor to dynamic markets, which are not public contracts.
What is still in scope
Payments under call-off contracts awarded in accordance with a framework, and contracts awarded by reference to a dynamic market, are covered where those contracts are public contracts, are awarded under a framework or dynamic market established under the Act, and the procurement for them commenced on or after 1 April 2026. The guidance also notes that a convertible contract modified under section 74(1) becomes a public contract, and section 70 applies from the point of conversion.
What it does not replace
The guidance states that the requirement does not replace existing expenditure publication requirements, including central government guidance for publishing spend over £25,000 and the Local Government Transparency Code 2015. Those continue to apply where relevant, so an organisation should expect to serve more than one disclosure from the same underlying payment data.
Questions CFOs and controllers should ask ERP vendors.
Practical Takeaway
Add one dimension to the payment, and the quarterly file writes itself.
The near-term work is bounded and mostly structural: tag the in-scope contracts by procurement commencement date, capture the platform identifiers at award onto the contract and vendor masters, preserve contract-level allocation through the payment run, hold gross and net values on the payment, record invoice receipt as its own timestamp, and upload monthly so the quarterly submission is a review. None of that requires a system replacement.
For ERP buyers this is a clean architecture test, and a portable one. A platform that treats a contract as a first-class dimension on payables, keeps external counterparty identifiers as governed master data, and can regenerate a period extract deterministically will absorb this obligation as configuration. The same capabilities serve e-invoicing mandates, supplier payment performance reporting, and contract drawdown analysis, which is why the investment outlives the specific rule that prompted it.
Sources
- Government Commercial Function, Cabinet Office: Guidance, Contract Payment Information (July 2026)
- Procurement Act 2023, section 70: information about payments under public contracts
- Procurement Act 2023, section 68: implied payment terms in public contracts
- Procurement Act 2023, section 69: payments compliance notices
- The Procurement (Amendment) Regulations 2026, which insert regulation 38A
- Cabinet Office procurement pathway guidance: payments compliance notices, receiving goods and services and issuing payments
- Browne Jacobson: Procurement Act 2023, key transparency changes in force for 2026
- Crowell & Moring: section 70 transparency and what suppliers need to know about significant payment notices