Budget Enforcement on POs
A budget without teeth is a suggestion. REDA Financials gives you the choice of dentures or fangs: in warning mode an over-budget purchase document posts with a caution; in enforcement mode it is refused until someone either finds the money or explicitly overrides. The same check runs on both sides of the buy: a purchase order when spending is promised, and a purchase invoice when the bill lands — so nothing slips the ceiling, whether or not it started as an order.
Access you'll need. Setting up budgets and turning on enforcement (an entity setting) requires the Accounting Admin v2 or Accounting Controller v2 permission set. The Accounts Payable v2, Accounts Receivable v2, and Read Only v2 sets see the budget check and its verdict on their purchase orders but cannot change budgets or the enforcement setting.
What happens when a PO posts
The PO finds its budget
The governing budget is a posted budget of the PO's entity whose period — its Start Date to End Date — covers the PO date. (The PO's Budget lookup even fills itself when exactly one posted budget covers the PO date; you can also pick it by hand.) Each PO line is then matched to the budget line with the same GL Account and the same dimensions — the same Cost Center (and any other dimensions your organization budgets by). Matching is exact, blanks included: a line with no cost center matches only a budget line with no cost center; a line tagged to the North office matches only the North-office budget line. A budget line can be less specific than the transaction line, never more.
Requested vs Available, per matched line
Line amounts (converted to the entity's currency) are totaled per matched budget line — that is, per GL account and dimension combination — and compared against each budget line's Available. Lines whose account-and-dimension combination has no budget line just note it — "No budget line found for …. Budget check skipped." — unbudgeted combinations are uncontrolled by design.
Verdict
Within budget → the PO posts and Committed rises. Over budget → "Budget exceeded for GL Account …: Available …, Requested …" — a warning in warning mode, a hard stop in enforcement mode. The PO's Budget Check field records the outcome (Within Budget / Over Budget / No Budget / Bypassed).
The budget fields on a purchase order
| Field | What it does |
|---|---|
| Budget (PO header) | A reference to the governing budget. Fills itself when exactly one posted budget of the PO's entity covers the PO date; with none or several candidates it stays blank for you to pick. Four rules police the pick — see the table below. |
| Budget Line (PO line) | Matched automatically from the chosen budget, the line's GL account, and its dimensions (Cost Center etc.) when exactly one budget line fits. On a Draft, change the line's account or a dimension and it re-matches on the spot — landing on the new budget line, or clearing if nothing matches. This link is what later routes the invoice's liquidation to the right line. |
| Budget Check (PO header) | The stamped verdict after posting: Within Budget / Over Budget / No Budget / Bypassed. Read-only history, great for list views. |
| Bypass Budget Controls (PO header) | The per-document override — see below. Off by default; every change to it is history-tracked. |
The Sterling PO, blow by blow
Meridian's $9,600 janitorial PO against Other Operating Expenses (budget line: $60,000 effective, nothing yet committed):
At posting: requested vs available
$9,600 requested against $60,000 available → within budget. The PO posts, its Budget Check reads Within Budget, and the line's Committed rises to $9,600 (Available: $50,400).
When Sterling's first bill arrives
The matched $4,800 invoice posts: Committed falls to $4,800, Actual rises to $4,800, Available stays $50,400 — the promise became fact, no new spending. Partial invoicing moves exactly the invoiced amount; the remaining $4,800 stays committed for Sterling's next bill.
Had the line been short
If Available had been less than the $9,600 requested, warning mode would post the PO with a caution, while enforcement mode would refuse it — "Purchase Order posting failed: Budget exceeded for GL Account …: Available …, Requested …" — naming the account and both figures, so the fix (trim, fund, or override) starts from facts.
Purchase invoices are controlled too
The purchase order is where spending is promised, but the purchase invoice is where it becomes fact — and both are checked. A purchase invoice carries its own Budget (a posted budget, selected exactly like a PO's), and how it touches the numbers depends on where it came from:
- An invoice matched to a PO inherits that PO's budget line and simply converts the commitment to actual — Committed falls, Actual rises, Available doesn't move. The order already reserved the money; the bill just changes its state. No double count.
- A direct-expense invoice (no PO) — utilities, one-off costs — stands on its own. It matches its own budget line by GL Account and dimensions (the same Cost Center logic as a PO, blanks matched exactly) and books the actual itself. With enforcement on, a direct bill that would drive a line's balance negative is refused: "Cannot post Purchase Invoice: budget balance would go negative for GL Account …. Reduce the invoice amount or increase the budget allocation."
- An account-and-dimension combination with no budget line is unbudgeted and uncontrolled, exactly as on the PO side.
Switching on the teeth
- Per entity: the entity setting Enforce Budget Controls flips that entity from warning mode (the default) to blocking mode. Meridian enforces on the US entity; a small new entity might run warnings-only for its first year.
- Per PO escape hatch: the Bypass Budget Controls checkbox on a purchase order skips the check entirely for that document — it posts regardless, its Budget Check reads Bypassed, and importantly its amounts never count against the budget. The field's changes are history-tracked; treat it as the emergency override it is, with a policy about who may tick it.
The rules, in the system's own words
| The message | What it means / what to do |
|---|---|
| "Budget Entity does not match the Purchase Order Entity. Select a Budget belonging to the same Entity." | Each company spends against its own budgets. |
| "The selected Budget is not Posted. Purchase Orders can only commit against Posted budgets." | Drafts aren't promises yet — post the budget first. |
| "PO Date falls outside the selected Budget date range. Select a Budget whose period covers the PO Date." | The PO belongs to a different budget year. |
| "The Budget cannot be changed once the Purchase Order is Posted — the committed amount is already rolled up to it. Void or unpost the PO to change its Budget." | The fourth rule, and the only one that bites after posting: the commitment is already sitting on the budget line, so the link is frozen. Unpost or void the PO first. |
| "Budget Line does not belong to the Purchase Order's Budget. Select a Budget Line from the same Budget." | Line and header must point at the same budget. |
| "Budget Line GL Account does not match the line GL Account. Budget commitment must track to the same GL Account." | Commitments track account-for-account — and dimension-for-dimension: a line's budget line must share its GL account and its Cost Center, so there's no cross-charging one bucket for another's spend. |
| "Purchase Order posting failed: Budget exceeded for GL Account …: Available …, Requested …" | The block (enforcement mode) — trim the PO, amend the budget, or bypass with authority. |
| "No budget line found for …. Budget check skipped." | A note, never a stop — that account simply isn't budgeted. |
| "Cannot post Purchase Invoice: budget balance would go negative for GL Account …. Reduce the invoice amount or increase the budget allocation." | The invoice-side guard, for lines already at or past their ceiling when the bill lands. |
After the check: the commitment ledger
- Posting a PO adds its line amounts to Committed on the matching budget lines; voiding or reopening the PO subtracts them back.
- When the matched invoice posts, the invoiced amount converts Committed → Actual (how the Committed-to-Actual flow works); with enforcement on, an invoice that would drive a line's balance negative is refused with a clear message.
- Bypassed POs stay outside this ledger entirely — visible on the PO record, absent from budget arithmetic.
Common mistakes to avoid
| Mistake | Why it hurts | Do this instead |
|---|---|---|
| Budget dates that don't cover the whole period you're spending in | Any PO dated outside the budget's Start–End range finds no budget, so nothing is enforced for it — the gap is silent | Set Start Date and End Date to span the full period; those dates (not the Fiscal Year label) are what the checks match on |
| Ticking Bypass Budget Controls as a routine unblock | Bypassed spending never registers as Committed or Actual — the budget goes blind to it, permanently | Treat bypass as the audited exception it is (its changes are history-tracked); fund real needs through amendments |
| Assuming a draft PO reserved its money | Only posting commits — two drafts can both look affordable and collide at posting | Post promptly, or re-run Budget Analysis just before posting |
| Expecting the block to police unbudgeted accounts | "No budget line found … Budget check skipped." — unbudgeted means uncontrolled, by design | Give every steered account a budget line, even a modest one |
| Reading "Over Budget" on the Budget Check as an error to clear | It's history — the verdict stamped when the PO posted in warning mode | Use it as the controller's worklist: filter POs by Budget Check and follow up |
Where to go next
- Budget Analysis Modal — check before posting, while drafting the PO.
- Budget Entries (Amendments) — the legitimate way to find more money.
- PO Budget Analysis — the AP-side view of the same check.
Frequently asked questions
Four, in rising order of ceremony: trim the PO; wait for other commitments to clear; ask the controller for a supplement or transfer to fund the line; or — with the authority your policy requires — tick Bypass Budget Controls. The block message names the account, the available amount, and the requested amount, so the conversation starts with facts.
Check three things: the entity's Enforce Budget Controls may be off (warning mode), the PO may have been bypassed (Budget Check = Bypassed), or the account may simply have no budget line (No Budget).
No — only posting commits. That's why the Budget Analysis modal exists: it previews the impact of the draft you're writing before any commitment happens.
Yes. A direct-expense purchase invoice matches its own budget line by GL account and dimensions (Cost Center) and books the actual itself; with enforcement on, a direct bill that would drive the line's balance negative is refused. An invoice raised against a PO doesn't re-check from scratch — it liquidates the commitment the order already made. So both the promise (the PO) and the standalone bill are controlled.
Voiding a posted PO — or reopening it to Draft — subtracts its amounts back off Committed, and Available recovers immediately. The budget always reflects live promises, not dead ones. (Bypassed POs never added anything, so cancelling them changes nothing.)
Not necessarily. Auto-selection only fills it when exactly one posted budget of the PO's entity covers the PO date — with zero or several candidates it leaves the choice to you. Pick the right budget by hand; the three selection rules (same entity, posted, date in range) will keep you honest.
The entity-currency amount: line values convert at the PO's exchange rate before the comparison, because the budget always lives in the entity's home currency. What's committed is the converted figure.
Was this article helpful?