Project cost control: one expense in two spreadsheets
The equipment was used on two projects, and both managers entered its full rental cost in their spreadsheets. When the figures are combined, someone has to find the duplicate and work out how to allocate the cost. A project cost application can retain a single source record and an approved allocation that each manager can open from their own project.
Syntalith
Where the project cost came from
Suppose a company rents equipment shared by two project teams. Both managers receive the same invoice line and copy its full value into their own cost sheet. The financial controller combining the project costs spots the duplication. They need equipment usage records to prepare an allocation under the company's finance-approved rule.
In the proposed application, the source line is recorded once. Alongside it, the controller can see the rental period and confirmed usage on both projects. They use those records to prepare an allocation for the designated reviewer to approve. A manager looking at their project's cost can open the shared source line and see how their portion was determined.
During the review, one manager notices that some equipment use on the other project is missing from the record. They supply the missing information, and the reviewer adjusts the allocation and records the reason. Once it is approved, both managers see the revised split. The controller can still open the earlier allocation and the explanation for the correction without reconstructing them from successive spreadsheet copies.
Agree on what the comparison includes
Finance defines how shared costs are allocated and which records support that rule. In this example, the basis is confirmed equipment use during the relevant period. The application applies the agreed rule and shows which proposed allocations still need review. A manager should be able to tell whether a figure in the report is a draft or an approved allocation.
Before comparing projects, the team also needs to separate costs already incurred from commitments for future work. Finance defines those categories and their data sources so that managers understand what they are comparing with the budget.
This scope supports internal project cost control. It can combine ERP data with allocations and managers' explanations while leaving accounting records in the existing system.
ERP features, an integration, or a custom application
Project cost control in Dynamics 365 supports comparisons of the original budget with actual and committed costs, depending on the selected forecast and configuration. This is a specific capability to investigate in your current project module.
Base the conversation with your administrator on one shared expense: can the system retain the source line, apply your allocation rule, and let someone revisit an approved correction? If it can, configuring the module may replace the additional spreadsheets. Budget-to-actual reporting alone does not establish how your implementation handles allocations between projects.
An integration makes sense when the ERP provides the right cost records, but managers keep equipment usage and explanations elsewhere. Connecting that information to the allocation review can remove the controller's manual transfer into the report. Access to source lines and their identifiers needs to be confirmed in the system you use.
A custom application is worth considering when that review regularly happens outside the ERP and the available module gives the team no convenient way to agree on shared costs. The scope could cover one cost type, its allocation, and the transfer of approved data into reporting. The work involved depends partly on the number of sources and how much cleanup the existing records need.
Keep the sources when moving open projects
Before moving the data, identify which rows in different spreadsheets refer to the same source line. For the equipment rental, keeping both full entries would reproduce the error in the new application. The controller needs to confirm the connection between the source and the projects and distinguish approved allocations from those that still need clarification.
A later export should include the source line, its allocation, and the reasons for corrections. A list of final project costs alone will not give a colleague taking over enough information to explain earlier decisions.
Agree with the developer who maintains the ERP connection and handles a source line that fails to arrive or appears again. Finance remains responsible for the rules and approval of changes. For a custom application, agree on ownership of the code and data, along with the documentation and access another developer would need to take over maintenance.
How Syntalith can connect project costs and allocation reviews
Through its custom software and integration services, Syntalith can connect records from your current system with shared equipment usage and the allocation approval process. Managers can explain their portion of a cost, while the controller retains the source and the review history. Your finance team supplies allocation rules and category definitions; project staff identify where usage records are created.
Tell us about a shared cost whose allocation recently caused a disagreement. Where was the same line recorded, and what information did the reviewer need? That example can help us determine whether your current module is enough or whether an integration or custom review workflow would help. See Syntalith pricing for information on how work is billed.
Assess whether custom software makes business sense
Compare your subscription, required features and workarounds with the cost of development, migration and ongoing ownership.
Explore custom applications