Connecting traded services with council finance

The handover problem

A traded-services operation produces commercial events: an order is placed, a contract starts, a quantity changes mid-year, a service is cancelled, an additional chargeable item is delivered. The council's finance system needs a clean, coded instruction for each of those events.

In many councils, that translation is manual. Someone reads the orders, works out the charge, applies the correct cost centre and coding, and produces a spreadsheet for the finance team to process. It works, but it is slow, difficult to audit, and the point at which most billing errors are introduced.

What goes wrong most often

• Missing purchase order numbers, causing invoices to be rejected or held by the school.
• Charges that do not match what the school believes it agreed, generating queries that take longer to resolve than to prevent.
• Mid-year changes applied to service delivery but not to charging, or vice versa.
• Cancellations processed operationally but still invoiced.
• Inconsistent coding between service areas, making income analysis unreliable.
• No clear audit trail linking an invoice line back to the order that authorised it.

Each is individually small. Collectively they consume a significant amount of officer time, and they erode trust in the traded-services operation from both directions — schools query bills, and finance queries the data.

An important boundary: this is not accounting software

It is worth being precise about scope. Councils run established finance systems — Unit4, Oracle, SAP, Civica, Access, Advanced and others — and those systems remain the accounting record. They handle the general ledger, invoicing, debt management, VAT treatment and statutory reporting.

A traded-services platform should not attempt to replace any of that. Its role is to be the accurate, structured source of what should be charged, to whom, for what, with what references — and to hand that over cleanly. Replacing the ERP is neither realistic nor desirable; feeding it well is where the value is.

What structured transaction data looks like

Rather than a list of totals, each chargeable event is recorded with the context finance needs:

• The customer organisation, with its finance identifiers.
• The service and product being charged, and the period covered.
• The pricing model applied and the inputs used — for example a per-pupil rate and the pupil count.
• Quantity, unit price and total, so the figure can be checked rather than trusted.
• The purchase order reference supplied by the school.
• Cost centre and coding information consistent with the council's chart of accounts.
• The originating order or contract, and the date and identity of confirmation.
• Status: pending, ready for export, exported, credited or adjusted.

With that structure in place, exporting to the finance system becomes a formatting exercise rather than an interpretation exercise — and that distinction is what removes the errors.

Handling the awkward cases

1. 1

   Mid-year changes

   Increases, reductions and cancellations need to produce explicit adjustment transactions with their own effective dates, rather than editing history.

2. 2

   Credits and corrections

   Corrections should be additive and traceable. Overwriting an original charge destroys the audit trail that resolves the next query.

3. 3

   Instalments and phasing

   Annual arrangements are often charged termly or monthly. Phasing should be derived from the arrangement rather than recalculated by hand each period.

4. 4

   Pupil-number revisions

   Where pricing depends on census data, define which census applies and whether in-year changes are re-priced. Ambiguity here is a recurring source of dispute.

5. 5

   Trust-level arrangements

   Where a trust purchases centrally for several schools, delivery and billing entities differ. That relationship needs to be modelled, not worked around.

Operational benefits beyond finance

Clean transaction data pays back outside the finance team as well. Income by service becomes reportable without reconciliation; commercial teams can see actual charged value against expected value; and service managers can see the financial consequence of delivery changes in the same period they happen rather than at year end.

Service Street is designed for exactly this division of responsibility: it manages the commercial side — catalogue, pricing, orders, contracts, purchase orders and transactions — and exports structured transaction data to the council's existing finance system. It is transaction management and export, not accounting software, and it does not replace the ERP.

In summary

The finance handover is usually the least designed part of a traded-services operation and one of the most expensive in officer time. Structuring transactions properly — with pricing inputs, purchase order references, coding and full traceability — reduces billing errors and disputes while leaving the council's finance system exactly where it belongs.