The buyer and approver paths

Reading the budget ledger

Reserved, committed, spent, remaining.

Sooner or later a controller at your customer will point at a number and ask why it says that. The ledger is the answer, and being able to read it out loud is the difference between a five-minute call and a reconciliation project.

Why it is a ledger and not a number

A budget field you decrement is wrong the first time an order is cancelled, and wrong twice the first time somebody adjusts it by hand.

So the remaining value is not stored as a fact. It is derived from an append-only list of movements, each recording what changed, by how much, why, and who caused it. What you see on screen is a cache of that sum, updated in the same transaction as the entry that changed it — which is what makes it safe for two buyers to hit the last €500 at the same moment. One of them gets it. Neither gets it twice. Nothing ever edits an entry; corrections are new entries.

The four states of money

State	Meaning	Counts against available budget?
Reserved	Held for a purchase request that is still waiting on a signature	Yes
Committed	The request was approved and the order created	Yes
Spent	Delivered and invoiced. Your customer's ERP knows about it	Yes
Remaining	The amount minus everything above	—

Reserved is the state that surprises people. Money held for a request nobody has decided on is unavailable to everybody else, and that is correct: two buyers must not be able to plan the same €500. It is also why an abandoned request is not a harmless thing sitting in a queue — see Approvals that get stuck.

The gap between committed and spent is where the ledger and the customer's ERP legitimately differ, and it is the first thing to check in any reconciliation. An order committed in December and invoiced in January belongs to different months in the two systems.

What an entry says

Each entry carries the value before, the value after, a reason, a reference to what caused it, and the person or process behind it.

Reason	Written when
`initialized`	The budget was opened for its period
`order`	A request reserved budget, or an order committed it
`withdrawal`	A hold was released — rejected, withdrawn, cancelled
`manual`	A person adjusted the budget by hand

Read down the list in order and you can narrate any remaining value from the opening balance. That narration is the whole product here.

manual entries are the ones to read. Everything else is the system doing what it was configured to do. A manual adjustment is a person deciding something, and it carries their name. If a budget has more manual entries than the customer expects, that is a governance conversation, not a data problem.

Several budgets on one cost centre

Where a cost centre carries more than one budget, they are drained in sequence order: the first to zero, then the next. An order of €8,000 against a cost centre holding €5,000 in sequence 1 and €20,000 in sequence 2 produces entries on both.

The last budget in the sequence may go negative. That is not a fault — it is where an overrun lands when the customer chose a soft limit, and it is the number their controller most wants to see. A cost centre showing −€2,340 in the last budget had exactly that much overrun approved by a named person.

Reconciling with the customer's finance

Do this in the first month of a customer's go-live, not the twelfth.

Pick one cost centre and one closed month.
Take the ledger entries with reason order for that period and sum them.
Ask the customer's controller for their booked total on the same cost centre for the same period.
Explain the difference before hunting for an error. The usual, legitimate causes:
- Timing — committed in one month, invoiced in the next.
- Cancellations and returns — released here, credited there, on different dates. See Returns.
- Tax — agree whether you are comparing net or gross.
- Orders placed outside the shop — phone and email orders never touched this ledger. Usually the largest gap, and the reason they wanted the shop.
Only then is a remaining difference worth investigating.

The ledger is not the customer's accounting system. It tracks what was committed through your shop against a budget they defined. It does not know about their other suppliers, their payroll or their leasing. Never let it be presented to their CFO as the department's total spend.

Period close

When a budget's period ends, close it deliberately rather than letting it lapse:

Clear the open reservations. Any request still undecided is holding money that is about to belong to a period that has ended. Decide them or withdraw them.
Read the final remaining value and give it to the customer's controller before the new period opens.
Handle the remainder according to the rollover choice — reset, or carried over as an additional budget ahead of the new one. See Budgets.
Check the negatives. A last budget in overrun is a real number their controlling department has to book somewhere. Do not let them find it in February.
Confirm the new period opened with an initialized entry at the full amount.

Orders placed in the old period and delivered in the new one stay booked where they were committed. Moving them would falsify both periods.

What to check

Take one budget and narrate it from initialized to today. If you cannot, an entry is missing a reference and that is worth raising.
Reject a test request and confirm two entries exist: the hold and its release, with matching amounts.
Compare remaining value against the sum of the entries. They should agree exactly.