We were deep in a design session recently for a nonprofit that delivers services and equipment to the people it serves. They're consolidating a pile of tools into Dynamics 365 on the customer side and Business Central on the finance side, and almost every question that came up boiled down to the same thing: does this live in the CRM or the ERP?
If you're standing up both Microsoft systems, this is the design decision that will either save you a lot of grief or create a lot of it. Here's how we think about drawing that line.
Put anything that touches money and inventory in the ERP
Business Central already knows how to track inventory quantities, cost, vendors, purchase orders, and revenue. That's the whole point of an accounting system, and it follows GAAP (Generally Accepted Accounting Principles) rules that you generally can't and shouldn't bend.
In this project, the team kept wanting to model cleaning supplies and equipment as inventory inside the CRM. Those supplies were bought with grant money, so they genuinely need to be tracked. But tracking quantities and their financial detail is exactly what Business Central does out of the box. So we pushed that work to the ERP. Same with budgets and allocations, and same with general purchasing that isn't tied to a client service order. There's no reason to rebuild inventory management in the CRM when it's already sitting there in the ERP.
If the answer to "who needs this number to close the books?" is the finance team, the record probably belongs in Business Central, not the CRM.
Keep customer history and service delivery in the CRM
The flip side: anything that's about a person, a relationship, or the coordination of a service belongs in Dynamics 365. Even something as simple as a cash donation splits across both systems. The revenue event lands in Business Central, but the history of who gave, and against which contact, needs to live in the CRM so the relationship record stays complete.
Service orders, claims to a payer, eligibility checks, and the coordination a caseworker does are all CRM work. They're about delivering and documenting a service, not about posting to the general ledger.
One value can exist in both, synced, not duplicated by hand
A recurring idea in the session was a "program" that ties grants, orders, and spend together. On the CRM side that can be a custom table. When those transactions sync to Business Central, that same program can map to a dimension value so posting and reporting downstream carry the tag. In Business Central, dimensions let you slice the general ledger by things like program, department, or location without creating separate accounts for each one.
So you're not entering the program twice. You define it where users work, and the integration carries it into the ERP so a finance report can filter straight to that detail. One source of truth, two systems that both understand it.
Why the CRM bends and the ERP doesn't
One thing worth knowing before you plan customizations: Dynamics 365 is very flexible about custom tables, renamed entities, and reshaped forms. Business Central is more constrained, because it's built around accounting rules, and some standard elements can revert on a Microsoft update. We'd soften any hard claim about exactly what reverts, since that varies, but the safe planning assumption is that the CRM is where you get creative and the ERP is where you stay closer to standard.
That difference should shape your design. Model the flexible, relationship-heavy work in the CRM. Let the ERP do the accounting it was built to do, and connect the two so a number entered once shows up everywhere it's needed.
If you're running both
Most of the mistakes we see with paired CRM and ERP setups come from putting a capability in the wrong system and then fighting the platform to make it work. If you're mapping out where inventory, billing, purchasing, and customer history should live across Dynamics 365 and Business Central, we're happy to talk it through and help you draw those lines before anyone starts building.