Setting Up Project Budgeting in Bitrix24

Why project budgeting diverges from actuals

An estimate usually lives separately from costs: the stage plan is kept in spreadsheets and files, while actual charging of hours, materials, and contractor work is recorded in the accounting system.

There is no link between these two contours, so the estimate and actuals can be compared only manually — export the data, break it down by stage, find where a plan line did not match an actual line.

Manual budget reconciliation is almost always delayed. While the analyst collects data and clarifies which stage a disputed expense belongs to, a decision on the project has already been made — and often based on figures a week old.

The divergence between plan and actual is discovered not when it arises, but when it has grown into an overrun across the entire project.

A separate problem is cost accounting by stage. Employee time is charged to the project as a whole, not to a specific stage, so it is difficult to determine after the fact which phase is eating the budget.

Hours, materials, and contractor work come from different sources, and each new reconciliation requires manual data normalization.

The price of such a scheme is managing the project by intuition. The manager sees that the budget is exhausted, but not at which stage or for what reason. Project budgeting ceases to be a control tool and turns into after-the-fact reporting.

Let's break down how this is closed: how to link the estimate to actual costs directly in the project contours, so that reconciliation happens automatically and for each stage.

What changes after implementation: the estimate reconciles with actuals

A unified estimate contour in Bitrix24: a project stage is a deal stage to which both planned amounts and receipt and write-off documents are linked.

Plan-to-actual by stage is built without exports into separate tables — the divergence is visible in the same card where the decision on the next payment is made.

Period close stops being manual assembly. Scheduled operations collect costs by project from posted documents and allocate them to cost items and stages according to specified rules, so the plan-to-actual snapshot is ready on the closing day, not after a week of reconciliations.

The share of operations without manual entry grows from half to most — only non-standard cases remain manual.

Deviation control works proactively: a threshold is set by cost item or stage, and when it is exceeded, the responsible person receives a notification before the expense goes into reporting.

This eliminates a whole class of errors — costs assigned to the wrong project, lost write-offs, and duplicated amounts that previously surfaced only during reconciliation.

Cost transparency changes the very logic of management: the profitability of a stage is visible at the moment it is performed, so resources can be reallocated based on fact, rather than after estimate approval.

Estimate management modes: tables, plan-to-actual, limits

In Bitrix24, a project estimate is described in three fundamentally different ways, and they are not interchangeable.

A simple table records the plan but does not prevent overruns; cost limits with an expense approval route stop spending before payment, but require configured roles; plan-to-actual analysis by cost item shows deviation when the period is already closed. The choice depends on where the control point is — before or after the expense.

In practice, the modes are combined: plan and actual live on linked entities, and a limit is placed on top only for those cost items where overrun is critical.

Then expense approval does not slow down the whole team, and the limitations of the modes remain predictable — the rule either works at the access level or is consciously disabled for a specific cost item.

How we configure project budgeting

Budgeting in Bitrix24 is not enabled with a switch: first we describe how project costs actually arise, are approved, and are closed in the company. We go from current accounting to a contour that calculates plan and actual in the context of projects, not accounting periods.

1. Audit of current accounting — we look at where the amounts come from: the estimate in the deal, team labor costs, purchases, contractors. We list the sources and manual tables in which the figures diverge.
2. Cost item scheme — a tree of cost items and dimensions: project, business line, cost item, responsible person. We mark plan and actual separately so that the project summary is assembled with a single query.
3. Approval routes — who requests costs, who approves, and at what amount the next level is involved. We build on robots, not on chat correspondence.
4. Contour setup — cost item directories, access rights, connection to tasks and deals, so that actuals are pulled from labor costs and purchases without double entry.
5. Testing on data — we run a closed period and compare plan-to-actual with manual calculation. We investigate discrepancies until they match, rather than attributing them to rounding.
6. Training and handover of the contour — regulations, role-based instructions, a settings map, and the procedure for changing cost items after launch.

After handover, changes in cost items and routes go through an approved procedure, so the contour does not drift a month after launch: new costs fall into the same dimensions, and reporting remains comparable.

Documents, schemes, and regulations that remain with you

Implemented budgeting lives not on a person who "knows where to click," but on documents that can be opened and checked. Below are the artifacts we hand over to your area of responsibility: a new employee, internal audit, and any subsequent enhancement rely on them.

• Budget item map — a hierarchy of cost items linked to departments and projects. A new cost item is added here, not by editing reports, so analytics does not diverge.
• Access matrix — who sees only their own cost center, who enters the plan, who approves, and who sees the summary. Rights are granted by groups, and upon termination, access is closed with one action.
• Approval scheme — request routes with thresholds by amount and deviations from plan, including escalation if the approver is silent longer than the deadline.
• Budgeting regulation — the procedure for forming the plan, versioning, carryover of balances, and rules for changing the approved budget.
• Instructions for executors — where to submit a request, which fields are mandatory, what to attach, and what to do in case of rejection.
• Period close regulation — deadlines for recording actuals, locking the period from edits, the plan-to-actual reconciliation procedure, and what to do with late documents.
• Set of checks before acceptance — test scenarios and reference data: after a portal update, one run confirms that calculations and routes have not broken.

The documents are in Russian, stored in the portal itself next to the working sections, and updated together with the process — a change to the org structure or approval rules is made in the regulation, rather than settling in correspondence.

Case: an estimate from scattered tables became a unified contour

Before implementation, the estimate for each business line lived in a separate table: the manager kept the plan, accounting kept the actual, and once a month manual estimate reconciliation began, line by line.

Quarterly reconciliation took three days, and discrepancies surfaced after approval, when some costs had already been posted. Manual entry errors were searched for by eye — most often these were lost lines and amounts entered twice for one cost item.

We assembled a unified budgeting contour in Bitrix24: cost items, responsibility centers, and limits became directories; the estimate became an element with "plan," "actual," and "reserve" fields and a version history.

Approval goes along a route with a record of who edited a line and when, and actuals are pulled from the accounting contour on a schedule — reconciliation turns into a report, not a recalculation.

Metrics before and after

The result of implementation — divergence is visible at the moment of entry, not a month later: calculation by cost item immediately highlights exceeding the limit and requires justification.

Version history preserves the previous approval, so returning to a prior estimate takes minutes rather than being reconstructed from emails.

Business line managers, instead of consolidating tables, analyze deviations — reconciliation takes a fraction of the previous time, and the period closes predictably.

How a limit differs from plan-to-actual by stage

These are two different mechanisms, and confusing them is expensive. Plan-to-actual by stage is measurement: the system compares the planned amount of a stage with actual expenses and shows the deviation.

A cost limit relates to management constraints — it is a rule that does not allow an expense above the threshold to be posted without a separate decision.

Plan-to-actual is built on the stage structure and on linking each expense to a stage and cost item. Without this link, expense analytics produces beautiful summary figures and zero benefit — it is unclear which stage pulled the estimate.

With the link, deviation is calculated automatically, and the manager sees not "an overrun in general," but a specific stage with a reason.

A limit begins where there is a point of no return — the moment of approval or posting an expense. It is no longer a report that works, but a check: when exceeded, the system stops posting or sends the document for additional approval.

The difference is fundamental: plan-to-actual says what has already happened; a limit decides whether it will happen at all.

Overrun control rests on three things: a threshold by stage or cost item, roles with the right to override, and a log showing who removed the restriction and why.

Without a role and a log, the limit becomes a number in a report that is bypassed through a neighboring cost item or by splitting an expense into parts.

Implementation order: first plan-to-actual and discipline of assigning stages, then hard limits on the most expensive stages. Otherwise, the system blocks legitimate expenses, and it is disabled along with the analytics.

Technical doubts before starting

Objections before starting are usually the same: what to do with already filled tables, will portal customization be required, who will see the amounts. Below are substantive answers; some tasks are handled by the platform's out-of-the-box tools.

Are out-of-the-box settings enough, or is portal customization needed?

First we assemble the process on standard mechanisms — they are enough for a budget register, requests, and approvals.

Customization is needed for your own plan-to-actual calculation or exchange with an accounting system; we package the code as a module so updates do not remove it.

How do we differentiate access to amounts?

At the level of roles and departments: a business line manager sees only their own budget, the finance team sees the consolidated one, an employee sees their own request without totals. We configure rights for sections and individual fields, and changes are recorded in history.

Who will know that the budget is exceeded?

We configure overrun notifications for a threshold as a percentage of plan: when a request is posted, the system compares actual with the limit and writes to the manager and the finance team, and in hard mode it stops the request until approval.

Let's discuss the cost accounting contour for your processes

So that the assessment of work is accurate and the implementation plan is realistic, we start with the source data: it shows the scope of setting up directories, the number of approval routes, and the depth of exchange with accounting systems.

The starting procedure is simple — you describe the task, we review it with your finance person and process owner, after which we return with an estimate and plan. Usually, in the first conversation we ask for the following:

• list of cost items and cost centers: how you currently classify expenses, where standards and limits for projects and business lines are stored;
• sources of actual data: which system the actuals come from, who is responsible for the export and how often it is done;
• roles and rights: who initiates the budget, who approves, at what level the route ends, and where change control is needed;
• required scenarios: planning from the estimate or from the previous period, budget versioning, adjustments and their history;
• reporting: what slices by project, business line, and period managers should see, in what form, and with what detail;
• data exchange: which systems to connect (accounting, HR, warehouse), in what format directories and entries arrive;
• constraints: launch deadlines, approval regulations, access to the portal and the test contour for configuration.

After the review, we fix the stages: prototype of directories and routes, data migration, report setup, role training, and launch with control over the first closed periods.