Your ERP does not store a budget
Every reporting project runs into the same question: where is the budget? Usually nowhere. Here is what you do then.
You build a report. Revenue is in there, margin, costs per category. Everything reconciles with the source.
And then someone asks the only question that matters: is that good or bad?
At that moment you have a problem, because a number without a reference says nothing. A hundred thousand euros in a month is excellent or disastrous and you do not know which of the two.
Where the budget is not
The answer is nearly always the same, and it surprises people every time: your ERP does not store a budget.
That is not a shortcoming. An ERP records what has happened. A budget is what you expect will happen. Those are two completely different kinds of data and most packages stick to the first.
Some do have a module for it, but it rarely gets used, and when it does get used it is usually once at the start of the year and never again.
In practice your budget therefore sits in an Excel file on the computer of the business owner or the accountant. Usually per year, sometimes per month, rarely per department or per channel. Quite often it does not exist at all and lives only in someone's head as a feeling about what it ought to be.
What usually happens then
Two things, both of them bad.
The report gets delivered without a reference. Nice charts, correct numbers, and nobody taking a decision on it because nobody knows whether it is going well.
Or last year gets used as a stand-in. That is better than nothing and it is also the trap, because last year is not a target. If last year was bad, this year looks good while you are still making a loss.
What to do instead
You make the budget an explicit part of the project, and you treat it as a data source like any other.
In practice that means: a table with an amount per period and per dimension you want to steer on. Per month, per channel, per location, whatever fits your business. That table hangs off the same date table as your actual figures, so comparing works automatically.
Where that budget comes from is a separate discussion. Preferably from the owner and the accountant together. If nothing exists, start with something rough: take last year, lay an expectation on top of it, spread it over the months according to your normal seasonal pattern. That is not accurate, but it is a target, and a rough target beats no target.
A warning from my own experience
When I built a model myself to demonstrate how this works, there was no budget whatsoever in the source data. I added a fictional budget table, calibrated so that the comparisons showed something.
That is fine for a demonstration and extremely dangerous the moment someone forgets it is fictional. A budget in a dashboard looks exactly as real as your revenue.
So: put a label on it. Call the table what it is, put the date it was set in there, and write down somewhere visible who approved it. If nobody approved it, that belongs on the label too.
The versioning problem
One more thing to think about early: a budget changes.
Halfway through the year it gets adjusted, and suddenly there are two truths. If you overwrite the old one, you can no longer see afterwards how you stood against the original plan. If you put them next to each other without a clear distinction, nobody knows which number is being shown.
So keep every version with a date and show the most recent one by default, with the option to see the original. That is a small intervention when setting things up and a big difference at the moment someone asks why the target moved.
The claim
A report without a budget is an information screen, not a steering instrument. And because your ERP does not have that budget, it is your job to decide where it comes from. Postponing that until the report is finished is the classic reason a dashboard never gets used.