Ledgerman
- Uncommitted = budget − committed. Negative means the project is over-committed.
- Open commitment = committed − actuals: work you've signed for but not yet accepted.
- Utilisation = actuals ÷ budget, and % committed = committed ÷ budget.
- Count a multi-year contract against each year's budget by its annual phasing, not by the date it was signed.
The three layers
Each layer answers a different question, and each comes from a different document.
The order matters. Money moves from budget to committed when a contract is signed, and from committed to actuals when work is accepted. At any moment, the budget splits into three parts: money not yet promised to anyone, money promised but not yet delivered, and money already spent.
A worked example
Project ALPHA has a 2026 budget of 1,200,000 EUR. By the end of June it has two contracts:
| Contract | Value | Phased to 2026 | Phased to 2027 | Accepted in 2026 |
|---|---|---|---|---|
| CRM implementation | 900,000 | 600,000 | 300,000 | 360,000 |
| CRM licences | 240,000 | 240,000 | 0 | 240,000 |
| Total | 1,140,000 | 840,000 | 300,000 | 600,000 |
The contracts are worth 1,140,000 in total, but only 840,000 of that is planned for 2026. The rest belongs to the 2027 budget. So for 2026:
Four figures to report
The three layers give four figures that tell a project manager and a finance controller where the money stands.
| Figure | Formula | ALPHA 2026 | What it tells you |
|---|---|---|---|
| Uncommitted | Budget − Committed | 360,000 | Budget still free for new contracts this year |
| Open commitment | Committed − Actuals | 240,000 | Signed work still to be delivered and accepted this year |
| % committed | Committed ÷ Budget | 70% | How much of the budget is already tied up |
| Utilisation | Actuals ÷ Budget | 50% | How much of the budget has turned into delivered work |
A project with 50% utilisation in June looks on track if you only compare budget with actuals. The committed layer adds the real constraint: only 360,000 is left to sign this year, not 600,000.
The same idea works per contract. The CRM implementation has 360,000 accepted of 900,000, so its open balance (value − accepted to date) is 540,000, and it is 40% delivered. The open balance covers the contract's whole life; the open commitment covers one year.
When the budget is zero, the ratios have no meaning. Show them as blank or "—", not as 0% or an error. A 0% suggests nothing was spent, which may not be true.
The monthly view
Budgets are approved per year but spent per month. Phase the budget by month, then compare it with the actuals of each month. The variance is actuals − budget, and the cumulative utilisation is year-to-date actuals ÷ year-to-date budget.
| Month | Budget | Actuals | Variance | Cumulative utilisation |
|---|---|---|---|---|
| Jan | 100,000 | 0 | −100,000 | 0% |
| Feb | 100,000 | 240,000 | +140,000 | 120% |
| Mar | 100,000 | 0 | −100,000 | 80% |
| Apr | 100,000 | 120,000 | +20,000 | 90% |
| May | 100,000 | 0 | −100,000 | 72% |
| Jun | 100,000 | 240,000 | +140,000 | 100% |
Acceptances are lumpy: licences are accepted at once and services at milestones. A single month's variance says little. The cumulative utilisation shows the trend, and here it says ALPHA is exactly on its phased budget by June. If the lumps don't match your budget phasing, phase the budget by the delivery plan rather than evenly.
Rolling up a portfolio
Portfolio totals are sums over projects. Ratios are not: recompute them from the summed amounts, never average them.
| Project | Budget | Actuals | Utilisation |
|---|---|---|---|
| ALPHA | 1,200,000 | 600,000 | 50% |
| BETA | 100,000 | 90,000 | 90% |
| Portfolio | 1,300,000 | 690,000 | 53% |
The average of 50% and 90% is 70%, which overstates the portfolio's utilisation by 17 points because it gives a small project the same weight as a large one. The right figure is 690,000 ÷ 1,300,000 = 53%.
Common mistakes
- Counting a contract in the year it was signed. A contract signed in December that runs for 18 months is mostly next year's money. Phase it across the years in which its work will be accepted. See how to phase a multi-year contract.
- Leaving out the committed layer. Budget vs actuals looks healthy until the contracts already signed exceed what is left. See why your budget spreadsheet hides over-commitment.
- Mixing documents in actuals. Invoices, payments and accepted work fall in different months. Pick one document as the source of actuals and use it everywhere. For delivered work, the acceptance date is when the cost belongs to the budget.
- Letting phasing drift from the contract value. If a contract's year split doesn't add up to its value, some money is counted twice or not at all.
- Accepting more than was contracted. Actuals above a contract's value, or above its allocation for a year, are either an error or an unapproved overrun. Both need a decision.
- Averaging ratios across projects or months, as shown above.
Tracking it in a spreadsheet or in Jira
A spreadsheet can do all of this: a budget sheet with 12 monthly columns per project and year, a contracts sheet with one column per year for the phasing, a certificates sheet with dated amounts, and SUMIFS formulas that bring them together. Our free portfolio budget tracker is built exactly that way, so you can start from it.
The trouble starts as the portfolio grows: formulas whose ranges miss new rows, phasing that no longer matches a contract's value, and several people editing one file. Time-tracking tools for Jira don't help here, because they cost work as hours × rates and have no committed layer.
Budget, committed and actuals in Jira
Ledgerman tracks the three layers for every project in Jira, from contracts and acceptance certificates rather than timesheets. It phases budgets by month and contracts across calendar years, calculates the figures above for each project and the whole portfolio, and points out where the documents and the budget disagree. You can import the spreadsheet you already have.