The check in the wrong place

In the first stage the purchase order clears. The technician looked at the balance left in the budget: checked. Eight weeks later the invoice arrives and we have a problem: the contract was signed by someone who did not have the authority to sign it. What the technician checked was correct, the balance was available. What was missing was the authority to approve it, a step the system was never programmed to check.

This is commitment control, and it is the one place in public financial management where the two come apart. Commitment control is meant to be the moment you decide whether the government may enter into an obligation at all. Most systems simply check if there is a balance left in the budget (or vote). That was needed, yes. That is a budget check, but control is not just a budget check.

The commitment that comes back to hurt you is rarely the one that makes the big announcement of exceeding your budget flag. It is the one that had budget, passed that part, but skipped over other checks of procedures. Other approvals that were not obtained, or multiple quotations, required, that were left off. Thresholds that were exceeded and should have been sent to a committee (were purchases purposely split up?) but were not. The standard check is almost always fine, because the standard question is the only question the system knows how to ask at the moment it matters.

And that is the crux of it. At the moment the commitment is made, budget balance can be checked and procedure is usually not. It is easy to see budget availability and check that. It cannot see whether three quotations were sought, whether the signer had the authority, whether the approval the financial manual requires actually happened before the order went out rather than after. So the system checks the thing it can measure and waves on through what it cannot, and we still call the result control.

Readers will recognise the budget office from last week. In the situation when a chart of accounts has three readers, we have the budget office reading the code string as control. It asks: was this expenditure authorised, is there room in the budget, could it have been stopped. That last clause is the one that gets lost. Could it have been stopped. A commitment check that only asks whether there is available budget can tell you that point, was there available budget. It cannot tell you whether the commitment could have been stopped, because stopping it depends on a procedure the system never saw.

To diagnose the problem, you look to see where the damage hits, and figure that is where the check should be, and it lands in accounts payable. You find that by the time a claim reaches payables, every decision that mattered has already been made. Someone followed the procedure or did not. The signer had the authority or they did not. Now at payment time the clerk holding the invoice can see the gap. They are the one who has to raise it, weeks after the goods arrived, with the supplier waiting and everyone above them wanting it settled. So the default answer, the only feasible answer because the system has to continue to function, is to pay it and note the exception. The exception register fills up with decisions that were made in the wrong place at the wrong time and can no longer be unmade.

Payables is where you find out the original price that was agreed. Commitment is where you agreed to it, that the purchase passed all procedural requirements. The time gap between those two is measured in weeks, and every week of it is a decision you can no longer influence, only record.

So the design question is not how to check the balance, which every system does. It is what parts of the procedure you can verify when you approve the commitment, before you create the obligation rather than after.

Some of it can be made a gate. Delegation is a fact the system can easily create: who may commit, up to what value, against which vote. That is enforceable at entry, the start of the process. Where it is enforced we find that situations such as the failure this piece opened with, a commitment signed by someone who did not hold the delegation, simply stop happening.

Some of these you can make required items that have to be available at the time commitment is requested. The approval reference, the procurement method, the committee minute number. Not the system judging whether the procedure was right, but the system refusing to let the commitment through unless these inputs, facts or steps to support proper adherence to procedure, are attached to the transaction, at the moment of the transaction, where it can later be checked against something rather than trying to reconstruct it after the fact.

And some of it genuinely cannot be enforced at commitment, and for that the upfront and honest move is to make the exception visible now instead of at payment. An exception raised at commitment is a decision, and does not look like a cover-up but more likely a forthright explanation. An exception raised at payment is a receipt, and raises suspicion.

None of this makes the procedure automatic. It makes the procedure clear and documented at the only moment when knowing about it still changes the outcome, and when the information is most likely available (and parts that are missing are noted). Budget availability is the part of control the system can always answer. The procedure is the part it usually cannot, and the reason it cannot is that the check, the verification, was placed after the decision instead of on it.

Move the check.