Business Central and CMMS Integration: Connecting Maintenance to the ERP

I have spent a large part of my career sitting in the gap between two systems that both think they own the truth about an asset. The maintenance team lives in the CMMS. Every asset, every work order, every planned maintenance task, every spare consumed and every hour of labour is recorded there, and to that team the CMMS is the system of record. The finance team lives in Business Central. Every purchase, every invoice, every stock movement, every cost center and every fixed asset sits there, and to that team Business Central is the system of record. Both are right about their own domain and both are wrong the moment they assume they own the other domain too. The whole discipline of CMMS to Business Central integration is about drawing that boundary cleanly and then moving the right data across it at the right time.

The message up front: a CMMS to Business Central integration is not primarily a technology project, it is a data-ownership project with a technical delivery attached. Decide which system owns each master record and each transaction, map the shared entities carefully, then choose the simplest interface that moves the data reliably. Get the ownership model wrong and no amount of clever middleware will save you. Get it right and even a modest batch interface delivers most of the value.

1. Why connect a CMMS to Business Central at all

Plenty of organisations run a CMMS and Business Central side by side for years with no integration at all, so it is worth being clear about what the gap actually costs before arguing for the effort of closing it. The gap is the finance-to-maintenance disconnect, and it shows up in a handful of very specific, very familiar pains.

The first pain is double entry. A maintenance planner raises a purchase requisition in the CMMS for a pump seal. Someone in procurement then re-keys that same requisition into Business Central as a purchase order because that is where suppliers, approvals and payments live. The same data is typed twice, which is slow, and worse, it drifts, because the two copies are never quite identical and nobody is sure which one is correct. Multiply that across every part, every contractor call-out and every consumable across a year and the re-keying alone is a measurable cost.

The second pain is invisible maintenance cost. Finance can tell you what was spent, but not always what it was spent on at the asset level. The CMMS knows a chiller consumed forty hours of labour and three thousand dirhams of parts last quarter, but if that never reaches the ledger against the asset or its cost center, the true cost of ownership of that chiller is a guess. Maintenance leaders end up unable to answer the single most important asset-management question, which is whether it is cheaper to keep repairing an asset or to replace it, because the repair history sits in one system and the money sits in another and the two were never joined.

The third pain is inventory that two systems both claim to control. The CMMS issues a bearing to a work order and decrements its own store count. Business Central, which handles procurement and stock valuation, knows nothing about it until a stock-take reveals the discrepancy. Now the two systems disagree about how many bearings exist, the reorder logic fires at the wrong time, and the stock valuation on the balance sheet is wrong. For the deeper mechanics of how Business Central handles this, the Business Central inventory management guide is worth reading alongside this.

Close the gap and those three pains disappear together. A requisition raised once flows to a purchase order without re-keying. Maintenance cost lands against the asset and the cost center so total cost of ownership becomes a real number. Inventory has a single truth so valuation and reordering are correct. That is the business case, and it is a strong one, but only if the integration is built on a clear division of responsibility rather than a tangle of two systems fighting over the same records.

2. What each system owns

Before a single field is mapped, the most important decision in the entire project is deciding which system is the master for each kind of data. This is not a technical decision, it is an operating decision, and it should be made by the business, documented, and then defended for the life of the integration. The clean starting position, and the one I recommend in almost every case, splits ownership along the natural strengths of each system.

The CMMS owns the maintenance world. It is the master for the asset register, meaning the equipment, its hierarchy, its location, its criticality and its technical attributes. It owns work orders, both the corrective work that responds to failures and the planned maintenance that prevents them. It owns the maintenance schedule, the failure history, the labour records and the task libraries. Anything that describes what maintenance is done, to what, when, why and by whom, belongs to the CMMS. Nothing in Business Central should try to be the authority on any of that.

Business Central owns the money world. It is the master for the chart of accounts, cost centers or dimensions, the general ledger, and all financial posting. It owns procurement, meaning vendors, purchase orders, goods receipts, invoices and payments. It owns inventory valuation and the item ledger, the stock quantities and their financial value. It owns the fixed asset register in the accounting sense, the capitalised value, depreciation and book value of assets. Anything that touches the ledger, a supplier or the balance sheet belongs to Business Central.

Notice that assets appear on both lists, and that is the single most important subtlety in the whole design. The CMMS owns the asset as a thing to be maintained: its make, model, serial number, location, criticality and maintenance history. Business Central owns the asset as a financial object: its capitalised cost, its depreciation and its net book value. These are two different views of the same physical equipment, and the integration has to link them without letting either system pretend it owns the other's view. I will come back to this asset duality repeatedly, because most of the integrations that go wrong, go wrong exactly here.

The rule that prevents most disasters: for every shared entity, exactly one system is the master and the other is a subscriber that receives a read-only copy. If both systems can edit the same record, you do not have an integration, you have two systems in a permanent argument. Write ownership down for each entity before you write a line of interface code.

3. The integration points that matter most

A CMMS and Business Central could in theory exchange dozens of data flows, but in practice a small number of interfaces carry almost all of the value. If you build only these, you have a genuinely useful integration. The rest are refinements. Here are the interfaces that matter, roughly in the order they usually pay back.

• Purchase requisitions and purchase orders. The maintenance planner raises a requisition in the CMMS for parts or contractor services. That requisition flows to Business Central, where it becomes a purchase order against the correct vendor, routed through the real approval and payment process. This is usually the highest-value interface because it kills the most re-keying and the most drift. The CMMS originates demand, Business Central executes procurement. For how the purchasing side receives and processes that demand, see the Business Central purchasing management guide.
• Spare parts and inventory sync. Both systems care about stock, but for different reasons: the CMMS to know whether a part is on the shelf for a work order, Business Central to value the inventory and drive reordering. Item masters, on-hand quantities and stock movements have to stay aligned so both systems agree on what exists and what it is worth. This is the interface with the most subtle failure modes, and I devote a whole section to it below.
• Vendor and cost data. Contractors, suppliers and service providers are mastered in Business Central because that is where they are paid. The CMMS needs a read-only copy so a planner can assign a contractor to a work order and so contractor cost can be captured against that work. Vendors flow from Business Central to the CMMS, never the other way.
• Work order costing. The CMMS accumulates the true cost of each work order: labour hours, parts consumed and contractor charges. That accumulated cost has to roll up into Business Central and post to the general ledger against the right cost center and, ideally, the right asset. This is the interface that finally makes maintenance cost visible in the accounts, and it is what turns a CMMS from an operational tool into a financial one.
• Fixed asset synchronisation. When a new asset is commissioned it needs to exist in both systems: in the CMMS as a maintainable object and in Business Central as a capitalised fixed asset. Keeping the two asset views linked, so the same physical pump has a stable identity in both, is what lets total cost of ownership be assembled from maintenance cost plus depreciation.

A useful way to think about these five is by direction of flow. Requisitions and work order costs flow from the CMMS into Business Central, because maintenance originates the demand and the cost. Vendors flow from Business Central into the CMMS, because finance owns the supplier. Inventory and fixed assets flow both ways in a carefully controlled manner, because both systems have a legitimate but partial stake in each. Draw those arrows on one page and you have the skeleton of the whole integration.

4. The data model: mapping across both systems

Every integration lives or dies on its data model, and the data model here is the set of shared entities that both systems reference and the keys that let them agree on what a given record is. There are four shared entities that carry the weight: assets, items, vendors and cost centers. Map these four cleanly and the interfaces almost design themselves. Map them sloppily and you spend the project firefighting mismatches.

Assets. As established, the CMMS masters the maintainable asset and Business Central masters the fixed asset. The mapping between them needs a stable, shared key, a code that identifies the same physical equipment in both systems and never changes over its life. In practice this is usually the asset tag or equipment number generated by whichever system creates the asset first, carried as a reference field in the other. The cardinal sin is letting each system invent its own asset number with no link between them, because then no query can join maintenance cost to book value and the total-cost-of-ownership promise evaporates. One physical asset, one shared key, two system-specific views.

Items. Spare parts and consumables exist as items in Business Central for procurement and valuation, and as stock items in the CMMS for issue against work orders. They must share an item code so that a bearing issued in the CMMS is unambiguously the same bearing valued in Business Central. Business Central is the natural master for the item master because it owns valuation and reordering, with the CMMS holding maintenance-specific attributes like which assets a part fits. The shared item code is the join key for every inventory movement that crosses between them.

Vendors. Suppliers and contractors are mastered in Business Central, where they are approved and paid, and copied read-only into the CMMS so they can be assigned to work. The vendor number from Business Central travels with the copy so that a contractor charge captured against a work order can be posted back to the correct supplier account. Never let the CMMS create vendors independently, or you will end up with two spellings of the same contractor and payments that cannot be reconciled.

Cost centers. This is the mapping that makes financial reporting work and the one most often overlooked. Business Central organises cost by cost center, department or dimension. The CMMS organises cost by asset, location or work order. To roll maintenance cost into the ledger meaningfully, every CMMS location or asset group has to map to a Business Central cost center or dimension value. That mapping table, however unglamorous, is what lets a chiller in the CMMS post its maintenance cost to the facilities cost center in the ledger. Build it deliberately and keep it current as the organisation restructures.

The honest pitfall: teams love to jump straight to interfaces and treat the data model as a detail to sort out later. It is the opposite. If assets, items, vendors and cost centers do not have agreed shared keys and a maintained mapping between the two systems, every interface you build will leak errors, and you will spend more time reconciling mismatches than you ever saved by integrating. The mapping tables are the foundation, not the finish.

5. Integration patterns

With ownership and the data model settled, the next decision is how the data physically moves. There is no single correct answer, only a set of trade-offs, and the right pattern depends on volume, timing needs and the skills available to build and run it. Business Central is well suited to modern integration because it exposes proper APIs, but that does not mean an API is always the right tool. The realistic options fall into three families.

API-based, point to point. Business Central publishes standard and custom web services, both OData and REST, so a CMMS can create purchase orders, read vendors or post journal entries directly against Business Central through its API. This is clean, real-time and avoids intermediate files. The cost is that you build and maintain the connection yourself, handle authentication, retries and errors, and cope with change on either side. It suits organisations with the development capability to own the interface and a genuine need for near-immediate data flow. The full surface of what Business Central exposes is covered in the Business Central APIs and integrations guide.

Middleware or iPaaS. Rather than wiring the two systems directly together, you place an integration platform between them: Azure Logic Apps, Power Automate, or a dedicated iPaaS product. The middleware subscribes to events or polls each system, transforms the data, applies the mapping, and delivers it to the other side. This costs more to stand up and licence, but it pays back by centralising the mapping and error handling, giving you monitoring and retry out of the box, and decoupling the two systems so a change on one side does not immediately break the other. For any integration beyond the simplest, this is usually where a serious organisation ends up.

Batch versus real time. Cutting across both of the above is the question of timing. A batch interface collects transactions and moves them on a schedule, for example every night. A real-time interface moves each transaction as it happens. Real time feels obviously better, but it is more expensive to build, harder to make resilient, and frequently unnecessary. A purchase requisition that becomes a purchase order within a few hours is fine for almost everyone. Work order costs that post to the ledger overnight are fine, because the accounts close monthly, not by the minute. Reserve real-time flow for the few cases that genuinely need it, such as an inventory check a technician makes before promising a part, and let everything else run in comfortable, reliable batches.

My practical bias, from doing this repeatedly, is to start with batch over middleware and add real-time API calls only where a concrete workflow demands them. Batch is easier to reason about, easier to reprocess when something fails, and forgiving of the inevitable data-quality surprises in the first months. You can always tighten specific flows to real time later. Starting real-time everywhere is how integration budgets get burned before any value is delivered.

6. Spare parts and inventory sync in depth

Inventory is the interface that looks simple and is not, so it earns its own section. The trouble is that a spare part has two legitimate owners with different needs. The CMMS needs to know, right now, whether a part is on the shelf so a work order can proceed. Business Central needs to know what stock is worth for the balance sheet and when to reorder. Both are looking at the same physical shelf, and keeping their two counts in agreement is where inventory integrations quietly go wrong.

The clean design starts by deciding who owns the store. In most facility and asset operations, the maintenance store is best owned by the CMMS for day-to-day movements, because that is where parts are physically issued to work orders, while Business Central owns the item master and the financial valuation. The flow then looks like this: item definitions and reorder policies originate in Business Central and copy to the CMMS. Physical issues and returns happen in the CMMS as parts go onto work orders. Those movements flow back to Business Central as inventory transactions so the item ledger and valuation stay correct.

The failure modes to design against are specific. The first is double counting, where both systems try to be the authority on on-hand quantity and drift apart; the fix is the single-owner rule, one system records the physical movement and the other receives it, never both counting independently. The second is timing gaps, where a part is issued in the CMMS but the movement does not reach Business Central before a reorder calculation runs, so the reorder fires on stale data; the fix is either tight enough batching or a real-time movement flow for fast-moving critical spares. The third is unit-of-measure and location mismatches, where a part is counted in boxes in one system and units in the other, or against different bins; the fix is agreeing units and locations in the mapping and validating them at the interface.

There is also a genuine judgement call about how much inventory detail to synchronise. Some operations keep every maintenance store as a full Business Central location with real-time valuation. Others treat the maintenance store as a single expense pool, issuing parts to cost as they are consumed rather than tracking every bin. The lighter approach loses some granularity but removes a great deal of integration complexity, and for many facility operations it is the right trade. Decide this consciously, because retrofitting full stock tracking onto an expense-pool design later is a substantial project.

7. Work order cost roll-up into the general ledger

This is the interface that changes what maintenance means to the rest of the business, because it is the one that makes maintenance cost appear in the accounts against the assets and cost centers that incurred it. Without it, maintenance is a line in the operating budget that finance cannot break down. With it, every asset carries its true running cost and the total-cost-of-ownership conversation finally has real numbers behind it.

The mechanics are a roll-up. As a work order progresses in the CMMS, it accumulates cost from three sources: labour, calculated from the hours technicians book against it at a labour rate; parts, valued as they are issued from the store; and contractor or external charges, captured from the purchase orders and invoices linked to the work. When the work order is completed and closed, the CMMS holds a total cost for that job broken down by those three components.

That closed-out cost then posts to Business Central as a financial transaction, and the mapping done earlier is what makes it meaningful. The work order carries an asset, the asset maps to a cost center or dimension, and the cost posts to the general ledger against that cost center, tagged where possible with the asset reference so cost can later be queried at the asset level. Parts cost typically relieves inventory as it posts, because the value is moving from stock to maintenance expense. Labour may post as an internal cost allocation or stay in the CMMS for operational reporting, depending on how the organisation treats internal labour. Contractor cost is usually already in Business Central through the purchase order and simply needs to be associated with the work order rather than re-posted.

The payoff: once work order cost rolls up cleanly, you can pull a report that shows the fully loaded maintenance cost of any asset over any period, sitting next to its book value and depreciation from the fixed asset register. That single view, cost to maintain against remaining value, is the number that drives repair-or-replace decisions, and it is impossible to produce reliably until the CMMS and Business Central are joined at this point.

A practical caution on timing and granularity: do not try to post every labour booking to the ledger in real time. The accounts do not need that resolution and the volume will overwhelm both the interface and the finance team. Roll costs up at work order closure, or summarise them on a periodic batch, and post at a sensible level of detail. The ledger wants the cost against the cost center and asset; it does not want a journal line for every fifteen minutes a technician booked. Choose a posting granularity that satisfies financial reporting without drowning it.

8. Governance: master data ownership and avoiding duplication

Every point I have made about ownership comes together as a governance question, because an integration is not a thing you build once and forget. It is a living arrangement between two systems that will both keep changing, and without governance the clean boundaries you drew at the start erode. New vendors get created in the wrong system. Someone adds an asset to the CMMS without a Business Central counterpart. A restructure invalidates the cost center mapping and nobody updates it. Six months later the integration is quietly producing wrong numbers and the trust is gone.

Governance for a CMMS to Business Central integration rests on a few concrete practices. First, a written master-data ownership matrix that names, for every shared entity, which system is the master, who is allowed to create records in it, and how the copy propagates to the other side. This document is the constitution of the integration and it should be agreed by both the maintenance and finance leadership, not just the technical team. Second, a single creation path for each shared entity: vendors are created only in Business Central, assets only in the CMMS, items only in Business Central, and the interface enforces this so a record cannot appear on the wrong side by accident.

Third, a discipline around the shared keys. The asset tag, item code, vendor number and cost center mapping are the join keys that make the whole thing work, and they must be protected from casual editing. A change to a shared key on one side without a coordinated change on the other silently breaks the link between records, and broken links are the hardest integration faults to find because nothing errors, the data simply stops matching. Treat shared keys as immutable once assigned, and manage cost center remapping as a controlled change with both systems updated together.

Fourth, active monitoring for duplication and drift. Even with good rules, duplicates creep in: the same contractor entered twice, the same spare with two item codes, an asset that exists in the CMMS but was never capitalised in Business Central. A periodic reconciliation, comparing the master lists on both sides and flagging records that exist on one but not the other, catches these before they compound. This reconciliation is unglamorous and it is the single most valuable ongoing habit in keeping an integration trustworthy. For the wider facility-management context in which this governance sits, the Business Central for facility management guide gives useful background.

9. Common integration pitfalls (and how to avoid them)

The ways a CMMS to Business Central integration goes wrong are remarkably consistent, and every one of them is avoidable with foresight. Across the projects I have seen, these are the patterns that recur.

• Both systems editing the same master data. The single most common and most damaging mistake. When both the CMMS and Business Central can create or edit vendors, items or assets, the two copies diverge and no one can say which is correct. The fix is the single-master rule, enforced at the interface, for every shared entity.
• No shared keys between assets. When the CMMS asset and the Business Central fixed asset have no common identifier, maintenance cost can never be joined to book value, and the headline benefit of the whole project is lost. Establish the shared key before anything else and never let it change.
• Building the interfaces before the data model. Teams eager to show progress wire up flows before the mapping tables for assets, items, vendors and cost centers exist. The flows then leak errors that trace back to unmapped or mismatched records. Finish the data model first, however tedious.
• Reaching for real time everywhere. Real-time flow is expensive and fragile, and most maintenance-to-finance data does not need it. Overreaching on timing burns the budget and destabilises the interface. Use batch by default and real time only where a workflow truly demands it.
• Ignoring the cost center mapping. Without a maintained map from CMMS locations to Business Central cost centers, work order cost posts to the wrong place or a catch-all account, and the financial reporting is meaningless. Build the mapping deliberately and keep it current through reorganisations.
• No error handling or reconciliation. Interfaces fail: a record is rejected, a movement does not post, a batch aborts halfway. Without visible errors and a reconciliation habit, failures accumulate silently until the numbers are wrong and trust collapses. Design monitoring, retry and periodic reconciliation in from the start.
• Treating it as a one-time project. An integration is a living system that needs ownership after go-live. Handed off to no one, it decays as both systems evolve. Assign a clear owner responsible for the mappings, the monitoring and the governance for the life of the integration.

None of these is a technology limitation. They are all decisions about ownership, sequence, scope and discipline, which is encouraging, because it means avoiding them is within your control rather than dependent on any vendor. The organisations that get integration right are not the ones with the fanciest middleware, they are the ones that decided ownership clearly and defended it.

10. A practical path to a clean integration

Pulling all of this together, here is the sequence I would advise any organisation to follow when connecting a CMMS to Business Central. The order matters more than the tooling.

• Step 1: agree ownership. Before anything technical, sit the maintenance and finance leaders down and agree, entity by entity, which system is master. Write the master-data ownership matrix and get both sides to sign it. This is the foundation everything else rests on.
• Step 2: build the mapping tables. Establish the shared keys and mappings for the four core entities: asset tag linking CMMS assets to Business Central fixed assets, item codes for spares, vendor numbers for suppliers, and the cost center map from CMMS locations to Business Central dimensions. This is the data model, and it is worth doing thoroughly.
• Step 3: start with one high-value interface. Do not attempt all five flows at once. Begin with purchase requisitions to purchase orders, because it delivers visible value fast and exercises the vendor and item mappings. Prove one interface end to end before adding the next.
• Step 4: choose the simplest pattern that works. Prefer batch over middleware for the first flows. Add real-time API calls only where a specific workflow needs immediacy. Resist the temptation to build a grand real-time architecture before you have proven the basics.
• Step 5: add work order costing. Once procurement and inventory flow cleanly, add the cost roll-up into the ledger, because this is the interface that unlocks total cost of ownership. It depends on the cost center mapping being solid, which is why it comes after the data model is proven.
• Step 6: instrument and reconcile. Build monitoring, error handling and a periodic reconciliation from the outset, not as an afterthought. An interface you cannot see failing is worse than no interface at all.
• Step 7: assign an owner and govern. Name a person responsible for the integration after go-live, keep the mappings current, and run the reconciliation on a schedule. The integration is a living system and it needs a steward.

Follow that sequence and you build value incrementally, each step resting on a solid foundation from the one before, with visible payback early enough to keep the organisation behind the project. The alternative, attempting all flows in real time before the data model is settled, is the well-worn path to an expensive integration that nobody trusts. For assets where you are also considering condition-based intervention that feeds work orders, the predictive maintenance guide pairs naturally with a clean CMMS-to-Business Central link, because the cost data the integration produces is exactly what justifies the reliability investment. And for the CAFM-specific angle on the same Business Central connection, see the CAFM and Business Central integration guide.

Final thoughts

The value of connecting a CMMS to Business Central is real and it is large, but it does not come from the technology. It comes from a clear division of responsibility, a carefully mapped data model, and the discipline to move the right data at the right time between two systems that each own a genuine and partial view of the same physical assets. The CMMS runs the maintenance, Business Central runs the money, and the integration is the honest conversation between them. Draw the ownership boundary cleanly, protect the shared keys, start with the highest-value interface, and govern the arrangement as the living thing it is.

The organisations that get frustrated with integration are almost never the ones whose middleware failed. They are the ones who let both systems edit the same records, who wired interfaces before agreeing the data model, or who built and then abandoned the connection with no owner. Avoid those traps and even a modest batch integration will pay for itself many times over, in re-keying eliminated, in inventory that finally agrees with itself, and above all in maintenance cost made visible against the assets that incurred it. That last outcome, knowing the true cost of keeping each asset running, is the number that changes how a maintenance function is run, and it is worth the discipline it takes to earn.

Related reading: CAFM and Business Central integration guide, Business Central APIs and integrations, Business Central for facility management, Business Central inventory management, Business Central purchasing management, Predictive maintenance and failure prediction.