By Artem Korsakov ·
For many contractors, accounting is already handled by an established accounting or ERP system. These systems handle procurement, inventory, supplier settlements, and bookkeeping. The project management side operates separately: estimates are in spreadsheet files, changes are tracked via correspondence, and cost forecasts reside in the project manager's head. When seeking to bring order to this chaos, the first thought is often radical: migrate everything into a single new system. Usually, this is expensive, time-consuming, and unnecessary.
It is more sensible to distribute the data so that each system performs its specific function without either maintaining the same data twice.
Why You Should Not Migrate Everything
The accounting system is already configured for bookkeeping, tax reporting, and employee workflows. Replacing it affects people who have no involvement in projects. Such a replacement is not required for managing project changes.
The existing accounting system usually functions correctly. What is missing is a bridging layer between the estimate and actual expenses.
As a result, the project manager manually assembles the picture: extracting expenses from accounting, matching them with estimates in spreadsheets, and adding changes from correspondence. Such a summary becomes outdated on the day it is created, and it is typically produced once a month by when corrections are no longer possible. Actual expenses exist in accounting, but there is nothing to compare them against: estimates are stored elsewhere and do not account for approved changes.
Who Stores Which Data
It is useful to start with a table where each type of data has a single owner:
| Data | Where Stored | Who Modifies |
|---|---|---|
| Nomenclature and supplier prices | Accounting system | Procurement |
| Purchases, inventory, payments | Accounting system | Procurement, accounting |
| Project estimate by sections | Project management system | Estimator |
| Changes and client decisions | Project management system | Project manager, client |
| Budget versions and cost forecasts | Project management system | Project manager, finance |
| Actual expenses | Accounting system, copy in project | Accounting department |
The key rule: the same value is not entered manually in two places. If actual expenses exist in accounting, they flow into the project management system via data exchange.
Three Budget Versions
Actual expenses are compared against three figures simultaneously. The baseline budget shows where we started. The approved budget includes agreed changes. Cost forecasts indicate how much the project will spend by completion, considering what is already known. In Autodesk cost reports these values are highlighted separately, and this separation should be replicated in any system.
Without three versions, discussions about cost overruns become arguments. The project manager argues that the budget increased due to client changes, while finance sees only the baseline figure. When changes are recorded separately, it becomes clear which part of the growth is approved and which is not.
Подпись: Educational project in million RUB. The dashed line in the fifth month shows obligations for which documents have not yet arrived.
How to Organize Data Exchange
Exchange between the project management system and accounting typically involves two directions.
From the project to accounting, approved change items and estimate sections are sent so that procurement and expenses can be attributed to them. From accounting back to the project, actual expenses are returned with attribution to specific sections.
Production-oriented accounting systems have their own data models. Check the production and project-accounting modules in the system you already use. The data model determines what expenses can be attributed to: orders, cost categories, or projects. This defines the granularity of reconciliation. Exchange details are designed during implementation on a specific configuration.
Verification: Are the Data Ready for Integration?
Before designing integration, answer these questions:
- Can every purchase in accounting be attributed to a project and an estimate section?
- Do estimate sections match how procurement groups purchases?
- Who currently updates cost forecasts and how frequently?
- Where are approved changes recorded, and can they be listed by project?
- Is there a directory common to both estimates and accounting, or do names diverge?
If estimate sections and accounting categories do not match, you must start with a common directory. Integration without it will transmit data that cannot be compared. The directory does not need to be detailed: ten to fifteen sections per project are usually sufficient to see where expenses diverge from forecasts.
What to Expect and What Not to Expect
Integration does not make forecasts accurate by itself. It reveals discrepancies earlier: by section and month, even before the project ends. Decisions are still made by the project manager.
Nor should you expect instantaneous accuracy in data exchange. Expenses enter accounting with delays: supplier invoices arrive after delivery, subcontractor acts are signed at the end of the month. Therefore, it is useful for the project management system to distinguish between confirmed actuals and obligations for which documents have not yet arrived. Otherwise, mid-month forecasts will appear better than they actually are.
Finally, integration requires an owner. Someone must review expenses that could not be attributed to sections and correct the directory. Without this work, after a few months, the project will accumulate an "other" line that explains everything and nothing.
In the demo scenario, you can trace how an approved change creates a new budget version, while the baseline estimate is preserved for comparison. Connection to accounting in the demo is not shown; this is a subject for future implementation.
Related article: Client Requested a Small Change. Who Will Calculate Its Full Cost?.
Sources and Scope of Examples
Sources confirm the described functions of ready-made products, not demand or return on investment for custom development. Scenarios and amounts are educational. Demonstrations use fictional data; real integrations, AI, payments, and external publication are not included.