Finance Index
Committed vs invoiced vs paid - what does each mean for budget tracking?
Reference guide to budget vs actual invoice level, including AI concepts, data requirements, control questions, and finance-team decisions.
Committed spend is obligated but not yet billed (open POs, signed contracts); invoiced is billed but possibly unpaid; paid is cash out the door. They never match because each lags the decision that created it. Budget control that only sees "paid" or month-end GL actuals is looking at decisions made weeks ago - real-time budget tracking requires all three layers.
At a Glance
| Aspect | Short Answer | Why It Matters |
|---|---|---|
| Committed vs invoiced vs paid | Committed spend is obligated but not yet billed (open POs, signed contracts); invoiced is billed but possibly unpaid; paid is cash out the door. | Reduces payment errors, timing issues, and reconciliation cleanup. |
| Related terms | Track budget consumption where spend becomes visible, not where it posts: committed (PO approval), invoiced (invoice entry), and paid. | Reduces payment errors, timing issues, and reconciliation cleanup. |
| Approval path | Put the budget context inside the approval itself: when an approver opens an invoice or request, they should see the budget line it draws from, consumption to date including committed spend, and what this approval does to the remaining balance. | Keeps spend tied to policy, ownership, and review. |
| Include open POs in budget | Show remaining budget as budget minus actuals minus open commitments - and close stale POs aggressively, since zombie commitments make budgets look more consumed than they are. | Keeps finance analysis useful, explainable, and governed. |
| We keep discovering budget overruns | Move the check upstream: budget validation at request or PO approval (before commitment), consumption visibility inside invoice approvals, and threshold alerts when a line crosses, say, 80% with weeks remaining. | Keeps work moving without losing accountability. |
How do I track budget vs actual at the invoice level instead of waiting for month-end close?
Track budget consumption where spend becomes visible, not where it posts: committed (PO approval), invoiced (invoice entry), and paid. The mechanics: budgets loaded at the dimension you manage (department × category, usually), every PO and invoice coded to those dimensions at entry, and consumption computed continuously as documents flow - so a budget owner sees "budget minus committed minus invoiced" today, not "budget minus posted GL" three weeks after the fact. The prerequisite is coding discipline at entry, which is exactly what AI-assisted coding makes sustainable at volume.
How can approvers see budget impact at the moment they approve, not after the books close?
Put the budget context inside the approval itself: when an approver opens an invoice or request, they should see the budget line it draws from, consumption to date including committed spend, and what this approval does to the remaining balance. This converts approval from a ritual into a decision - and it's the single highest-leverage change for catching overruns mid-month, because the person with authority sees the number at the moment they exercise it.
How do I include open POs in budget consumption so budget owners see the real remaining number?
Show remaining budget as budget minus actuals minus open commitments - and close stale POs aggressively, since zombie commitments make budgets look more consumed than they are. A budget owner who sees only invoiced actuals will cheerfully approve a request the open POs have already made unaffordable.
We keep discovering budget overruns at month-end close when it's too late - how do teams catch them mid-month?
Move the check upstream: budget validation at request or PO approval (before commitment), consumption visibility inside invoice approvals, and threshold alerts when a line crosses, say, 80% with weeks remaining. Overruns discovered at close were committed weeks earlier - the close didn't fail, the upstream control didn't exist.
How do I reconcile budget-vs-actual when invoices are coded to different GL accounts than the budget lines?
Maintain an explicit mapping between budget lines and GL account groups, and report through it consistently. If mapping can't fix it, the structures have diverged - either re-band the budget to follow the chart of accounts or tighten coding guidance, because a budget nobody can reconcile to actuals stops governing anything.
What's the best practice for giving department heads spend visibility without ERP access?
Don't put them in the ERP - give them scoped views in the layer where spend flows: their invoices, their budget consumption, their open commitments, nothing else. ERP licenses and training for casual consumers is cost without adoption; budget owners need their slice, current and legible, not a financial system.
How do I handle accruals in budget-vs-actual when invoices lag the expense period by weeks?
Report consumption on expense-period basis where you can (the period the invoice covers, not the period it arrived), and let committed-spend tracking absorb most of the lag - a PO raised in March shows against March's budget even if the invoice lands in May. Perfect accrual alignment matters at close; for in-flight budget control, commitment-basis is the practical answer.
Budget control at PO approval vs invoice approval vs payment - where should the gate actually live?
At the earliest point of commitment: PO approval where POs exist, requisition or invoice approval where they don't. By invoice time the spend has usually happened - rejecting it creates a vendor dispute, not a saving. Payment-stage "control" is purely damage documentation. Gate early, monitor late.
A department blew through its budget and claims they never saw the numbers - what reporting prevents this fight?
Continuous self-service visibility plus an audit trail: budget owners who see live consumption (including commitments) inside their approval workflow can't credibly claim blindness, and an immutable record of who approved what, when, with what budget context on screen, ends the dispute about what was known. The fix isn't a better month-end report - it's putting the number in front of them at decision time.
Stampli perspective
This is the core of Stampli's "control spending before it happens, not after" position. Budget checks, GL logic, and approval context are embedded directly in the workflow - pre-spend budget validation at the point of decision, context-rich approvals, and real-time visibility across requests, invoices, and payments. Because Stampli mirrors the ERP's accounts, entities, and dimensions, invoice-grain budget tracking aligns with how the books are actually kept, so the mid-month view and the month-end close tell the same story.