Budgeting in most medium and large manufacturing companies follows a similar pattern: a dozen or so Excel spreadsheets circulating via email among department managers, manual consolidation into a single file by the controlling department, and a week of work before anyone sees the full picture. The problem is not that people cannot plan their department’s budget — the problem is that there is no single place where these plans live, update, and can be compared with actual performance.
Below, we show how we approach building such a system — from financial structure, through individual accountability, to the place where the budgeting logic actually resides.
1. Budgeting starts with the P&L structure, not the form
Before anyone starts entering numbers, a framework is needed: a profit and loss statement broken down in the way the company actually manages its business — by cost centers (MPK), segments, product lines, or locations, depending on how accountability is organized within the organization.
This breakdown subsequently determines everything else:
- the level of granularity at which someone plans (department, cost center, project, contract),
- how accounting accounts map to P&L lines,
- where the boundaries of responsibility for individual managers lie within the structure.
The most common error that prolongs the budgeting cycle is designing the budget form before establishing this structure. In such cases, the form needs to be rebuilt every time the organization or chart of accounts changes.
2. Accountability and Permissions: Who Budgets What
Since the P&L is divided into responsibility centers, the budget should be completed by the individuals who are actually accountable for those areas — not centrally by the controlling department based on emails and phone calls.
In practice, this means a layer of permissions built around the organizational structure:
- the cost center owner sees and edits only their area,
- the regional manager sees an aggregated view of subordinate cost centers but does not edit them directly,
- the controlling department has a comprehensive view and the right to make adjustments during consolidation,
- every change has an approval workflow — a department budget is not ‘ready’ until it passes through the appropriate level of acceptance.
This is not a matter of tools, but of data models and roles — yet it is this model that allows dozens of people to work concurrently on a single budget without overwriting each other and without a week of consolidation at the end.
3. Interface Layer: Adapting to Infrastructure, Not the Other Way Around
This raises the question of where people actually fill out these forms. The answer is not singular — it depends on what the company already has. The principle we follow: the budget form should be located where the person already works, not in another system that requires a separate login.
Two typical scenarios:
The client works in CRM (e.g., Dynamics 365 Sales / Customer Service). We embed the budget form as a Power Apps canvas app directly within the CRM — the regional manager plans the sales budget in the same place where they manage the pipeline and customer accounts, without switching context.
The client has Dataverse and Microsoft Fabric. Here, the form feeds Dataverse tables, which, through the mechanism of linking tables with Fabric (Dataverse–Fabric link), go directly to the data layer in Fabric — without additional ETL integrations between the data entry system and the data warehouse.
More variants are possible — SharePoint Lists, Teams, a dedicated portal. In each case, the decision about the interface is made after analyzing where a given user group already works, not upfront as a single ‘correct’ tool.
4. Where the Budgeting Logic Actually Resides: Data Warehouse, Not a Spreadsheet or a Form
This decision has the greatest impact on how much the company benefits from this process in the long run. The interface (Power Apps, form, SharePoint) is merely a data entry point. The budgeting logic — consolidation rules, allocations, budget versions, plan/actual comparisons, scenarios — should reside in the data warehouse, not be embedded in a form or spreadsheet.
Thanks to this:
- the budget and actual performance data (from ERP, production system, CRM) flow into the same data model and compare one-to-one, without manual linking,
- multiple budget versions can be maintained (original, revised, rolling forecast) without multiplying files,
- changing the reporting tool or data entry interface does not require rebuilding the logic — because the logic is not tied to these tools,
- variance analysis, drill-down to a single transaction, or ‘what-if’ simulations are possible without additional programming work, because all data is already in one place, in a consistent model.
This is a reversal of the typical approach where budgeting logic lives in Excel formulas or in the configuration of a single SaaS tool. When the logic is in the data warehouse, the reporting layer (most often Power BI) becomes merely a window into the data — not a place where it needs to be calculated.
Summary
Well-organized budgeting, in practice, involves four decisions made in the correct order:
- A P&L structure that reflects real accountability within the organization.
- Permissions and workflow tailored to who actually manages a given area.
- A data entry interface embedded where people already work — adapted to the client’s infrastructure, not imposed externally.
- Budgeting logic maintained in the data warehouse, independent of the interface and reporting tool.
This order matters: companies that start by choosing a tool usually end up with a system that needs to be rebuilt with the first organizational change. Companies that start with structure and data models gain a system that scales with the organization.