Don’t Just Migrate – Rethink Job Costing Beyond Dynamics GP
For many organizations using Dynamics GP, job costing has worked for years. Until it doesn’t.
As GP approaches end-of-life, companies are being pushed to move – but when job costing is complex, the real question becomes:
“Can we just move this to Business Central?”
In one of our recent implementations, we learned that the answer is no – not directly. What’s needed is not a migration, but a re-architecture.
Let’s look at why, using a smaller, real-life example.
The Starting Point: Job Costing That “Works” in GP
Our client had been using:
- a. Dynamics GP for finance
- b. A job cost solution built on top of GP
- c. Cost codes for labor, material, and subcontracting
- d. Percent of Completion (POC) revenue recognition
The system worked – but it was tightly tied to GP logic and tables. When the move to Business Central was discussed, it became clear that a straight migration would carry old limitations into a new system.
Why Business Central Alone Was Not Enough
Business Central’s Jobs module is powerful, but it is best suited for simpler job structures. The client needed:
- a. The ability to revise forecasts without changing original estimates
- b. Clear visibility into cost overruns mid-job
- c. Change orders that impacted both cost and billing
- d. Reliable POC calculations period over period
Trying to force all of this into standard BC Jobs would have meant heavy customization and long-term maintenance risk.
So instead, we rethought the design.
The Re-Architecture Approach
We clearly separated responsibilities:
- a. Power Platform managed operational job costing logic
- b. Business Central handled financial postings and reporting
This allowed us to keep Business Central clean while still supporting real-world job complexity.
A Real-Life Example
A company wins a project worth $50,000.
Job Setup
- – A job is created
- – Cost codes (Labor, Material, Subcontract) are assigned
- – The original estimate is entered and locked
This becomes the baseline for performance tracking.
Committed & Actual Costs
- a. Purchase orders create committed costs
- b. Vendor invoices and labor entries create actual costs
Now management can compare: Estimate vs Committed vs Actual – and see margin trends early.
Forecast Revision
Labor is running higher than planned.
Instead of changing the original estimate:
- a. A forecast revision is created
- b. Expected margin is updated
- c. Audit history remains intact
Change Order
The client approves an extra $5,000 scope.
- – The contract increases to $55,000
- – Budget and forecast are updated
- – POC recalculates automatically
Percent of Completion (POC)
At month-end: Revenue is recognized based on actual cost incurred. Finance gets accurate revenue, WIP, and margin – without manual adjustments.
Why This Architecture Worked
This approach delivered:
- a. Accurate financials in Business Central
- b. Flexible job costing without over-customizing BC
- c. Clear visibility for project managers
- d. Reliable POC for finance teams
Most importantly, the system supported how people actually run jobs – not just how software expects them to.
The Bigger Lesson: Don’t Migrate Problems
When moving from Dynamics GP to modern platforms, the goal should not be to recreate the past. It should be to:
- a. Preserve what works
- b. Fix what causes manual work
- c. Design for scale and future growth
Job costing is not just a module – it’s a business process.
Final Thought
If you are planning a transition away from Dynamics GP and rely on job costing, ask yourself: Are we simply moving systems – or are we redesigning job costing for better control and visibility?
The answer makes all the difference.
I hope you found this blog useful. If you would like to discuss anything further, feel free to reach out to us at transform@cloudfronts.com.
