The Budget Warning Arrives After the Approval

Ask a county finance officer what their budget says and you will get a careful answer, because there are at least three defensible numbers. There is what has been paid. There is what has been received and invoiced but not yet paid. And there is what has been ordered — money that is not in anyone's account yet but is no longer available to spend on anything else. The third number is the one that stops an overspend, and it is the one most business software does not carry.

Commercial accounting can afford to be relaxed about this. A company that overspends a departmental budget has a management problem. A public entity that overspends a vote has an audit finding, and possibly a personal one for whoever authorised it. The distinction between committing money and spending it is not accounting pedantry in that setting — it is the control.

This post says exactly how our product handles those three moments. One part of the answer is better than people expect, one part is weaker than the language around budgets usually implies, and the third part does not exist at all.

The good part: the budget consumes at commitment

A budget in this product is an amount for a department and a category over a period. Its consumption is not computed from payments and not from invoices. It is computed from purchase order lines, counting every order whose status is approved, processed, completed, delivered or paid.

That is the correct model. The moment an order is approved, the money it represents stops being available, whether or not anything has been delivered and long before anyone has been paid. The remaining figure on the budget screen is what you can still commit, which is the number a budget holder actually needs.

A cancelled or rejected order falls outside that status list, so cancelling an order releases the commitment automatically. That is also correct, and it is the kind of behaviour that is easy to get wrong.

The part worth knowing: the check does not stop you

There is a budget availability check, and it runs at two points — when a [request for quotation](/glossary/request-for-quotation) is approved, and again when the resulting purchase order is approved. It totals the lines by category, looks up the matching budget, and works out whether the new amount fits in what remains.

When it does not fit, here is the sequence, in the order it happens in the code. The check returns a failure. The violation is recorded, with the remaining balance. The request is then approved. Two notifications are sent: one saying the request was approved, and a second saying it was approved with a budget warning.

A control refuses. A warning explains. This one explains, after the fact, to whoever happens to read notifications.

It is worth being clear that this is not a failure of the calculation. The arithmetic is right, the remaining balance in the message is accurate, and the person who approved it does get told. It is a reporting behaviour rather than an enforcement one, and if you are specifying a system on the basis that it will prevent an over-commitment, that is the distinction that matters.

The same codebase does hard-block elsewhere, which is what makes this a design choice rather than an oversight. A purchase order cannot be closed without a goods receipt — attempt it and the action is refused outright with an error. So the machinery for a refusal exists and is used. The budget is not wired to it.

Three things about the calculation to know before you rely on it

These are not defects so much as behaviours with consequences, and each of them can make a budget figure quietly wrong in a way nobody notices.

One. Category matching is an exact text match on the item

A budget is for a category, and consumption is matched by comparing the budget's category to the item's category as lowercase text. Exact match or nothing. An item categorised "Office Supplies" will not consume a budget named "Office supply", and a line whose item has no category set will not consume any budget at all.

The consequence is the dangerous kind: it does not produce an error. The order goes through, the budget simply does not move, and the budget screen shows more money remaining than there really is. If you take one operational action after reading this post, make it a review of your item categories against your budget categories.

Two. The period is matched on when the order was created

Purchase orders are matched to a budget period using the date the order record was created, not its order date and not its approval date. An order raised on the 29th of one period and approved in the next belongs, for budget purposes, to the period in which it was raised. For a financial year boundary that distinction is not academic.

Three. A budget without a department matches everything

The department filter is applied only when the budget has a department set. A budget created without one will draw consumption from every department's orders in that category. That is reasonable behaviour for an organisation-wide budget and misleading if the omission was accidental.

The part that does not exist: reconciliation

Here is the third moment, and the gap that a finance officer will find first.

The budget records the commitment at order approval and then stops looking. The general ledger, separately, records the transaction when goods are received — a check-in debits inventory and credits either accounts payable, an inventory clearing account or work in progress, depending on what the receipt is for. Payment is a third event again.

Nothing compares the first number to the second. If you order a hundred units at five hundred each and are ultimately invoiced for ninety units at five hundred and twenty, the budget goes on reporting the original fifty thousand for as long as that budget exists. There is no committed-versus-actual variance anywhere in the product.

The budget detail screen does show a projection variance, and it is worth not misreading it: that compares a projected total against the budget amount. It is a forecast against a limit, not a comparison of what was committed against what was eventually spent.

What to do with this

None of the above makes the budget module unusable. It makes it a particular kind of tool, and these are the steps that get the most out of that tool honestly.

1. Align your item categories with your budget categories, exactly

   One list, one spelling. This is the single highest-value hour anyone can spend in this module, because the failure mode is silent.

2. Always set a department on a budget unless you mean otherwise

   A budget without one draws from every department in that category, which will look correct right up until it does not.

3. Treat the warning as a report, and give it an owner

   The over-budget notification goes to the approver. If nobody is accountable for reading and acting on those, the information exists and the control does not.

4. Reconcile committed against actual outside the system, on a cadence

   Monthly, comparing purchase order values against what the ledger recorded on receipt. It is a spreadsheet job today, and knowing that is better than assuming it happens.

5. Mind the period boundary

   Orders raised near the end of a period belong to that period by creation date. If that is the wrong answer for your financial year, plan the cut-off around it.

The questions to put to any vendor

The second question is the one to insist on. Almost every product will answer the first one correctly in conversation. Watching the second one happen on screen tells you whether you are buying a control or a report, and that is the distinction your auditor will be working from.

A budget that warns is worth having. A budget that refuses is a different product decision, and one we would rather make deliberately with a finance officer than discover in an audit. What matters for anyone evaluating now is knowing which of the two is sitting in front of them.