CMMS vs ERP: Where Maintenance Should Live

Pump P-104 fails at 2:00 AM. The technician finds a failed bearing. Within the next week that single event will touch maintenance, stores, purchasing and accounting.

The ERP may already know the bearing item number, the approved supplier, the quantity on hand, the unit cost, the purchase order, the invoice and the general ledger account it posts to. The CMMS may know P-104, the failure, work order WO-8471, the technician assigned, the maintenance procedure followed, the findings recorded and the repair history that now includes one more bearing.

Both systems can hold entirely correct information about the same event. They are answering different questions.

There may not be one truth to own. There are different truths about the same event.

Maintenance should live where maintenance decisions can keep their operational context. Financial control should live where enterprise transactions can keep their financial integrity. The integration boundary exists to preserve the relationship between the two.

This guide does not argue that a CMMS must be separate from the ERP, and it does not treat ERP maintenance modules as inferior. Some ERP suites contain substantial maintenance capability. The question that matters is whether the implemented system can support the maintenance operating model at the depth the organisation needs while preserving enterprise financial and transactional control.

Evaluate the implemented maintenance model, not the logo on the software.

This is a responsibility-design problem

The usual comparison — CMMS manages maintenance, ERP manages the business — is true and almost useless. It tells a buyer nothing about where a requisition should originate, which system decides whether a part is available, what maintenance sees when finance rejects a charge code, or which number appears when someone asks what P-104 cost last year.

Those are design decisions. They get made during implementation whether or not anyone makes them deliberately. A buyer who maps them in advance is designing an operating model. A buyer who does not is inheriting whatever the interface happened to do.

The Three Realities

A single maintenance event exists in three realities at once, and they are not necessarily modelled at the same level of detail.

Physical Reality

What physically exists: the pump, the motor, the gearbox, the valve, the production line, the building system, the location, the equipment configuration. What is physically connected to what, where it sits, what function it performs, and what changed physically.

Maintenance Reality

What must be maintained: what can fail, what gets inspected, what receives preventive maintenance, what work occurred, what parts were consumed, what technicians observed, and what history must remain attached to the equipment.

Financial Reality

What has been financially recognised: what was purchased, what was capitalised, what expense was recognised, which account or cost centre owns it, what inventory value changed, which invoice was paid, and which financial asset is being depreciated.

These three realities overlap, but they are rarely modelled at the same granularity — and no single system necessarily owns an entire reality.

Financial asset is not the same as maintainable asset

Finance may capitalise one thing: Packaging Line 3, fixed asset FA-00821. Maintenance may maintain six: conveyor C-301, motor M-301, gearbox G-301, photoeye PE-301, drive VFD-301 and sealer S-301.

Both structures are legitimate. They exist because finance and maintenance are answering different questions. The relationships between them can take several shapes: one financial asset may correspond to many maintainable assets; several capital projects may touch one maintainable asset over its life; a project or cost structure may span multiple maintainable components.

Do not evaluate a CMMS–ERP integration by asking whether the asset counts match. Ask whether the relationships between the different representations can be preserved.

Public procurements show organisations solving this explicitly. The City of Mobile's enterprise asset management solicitation asks for the ability to store a different asset ID on the asset record — specifically the fixed asset ID from the City's financial system — in a searchable user-defined field. That is an identity bridge, not a merged hierarchy. Tacoma Public Utilities took a similar position in its CMMS procurement: SAP remains the system of record for asset master data, the CMMS and the GIS mirror SAP at the asset ID level, and the structure of the hierarchy inside the CMMS does not need to replicate SAP's hierarchy as long as asset-to-asset alignment holds.

Identity is shared. Structure is not. That distinction is worth carrying into every demo.

“System of record” is too crude

Someone in the room will say the ERP is the system of record. The only useful response is: for what?

The phrase compresses a dozen separate ownership decisions into one word, and the compression hides exactly the decisions a buyer needs to make. In practice, different objects have different owners.

These are examples, not prescriptions. Organisations divide these differently for defensible reasons. The point is that the division is object-by-object, and that a buyer should be able to say it out loud.

Spokane Transit's enterprise asset management procurement shows the granular version in writing. Asked to confirm that accounts payable, accounts receivable, taxation and general ledger would remain in Tyler ERP as the systems of record, with the EAM posting and consuming costs through defined interfaces, the agency answered yes. The same procurement confirmed it would name authoritative data owners for each data domain — assets, inventory, vendors and costs — to approve mapping rules. Ownership is stated per domain, not per product.

Authority by Meaning

Even one shared object carries several different meanings, and they can have different owners.

The ERP can own the identity of bearing 6208-2RS and the transaction that received it. The CMMS can own the fact that P-104's inboard bearing failed under high vibration and that the replacement lasted eleven months. Neither system needs to own all four meanings for the organisation to have a complete picture.

One system does not need to own every meaning attached to the same object.

Create, govern, consume

A practical way to turn authority into implementation decisions is to ask three questions about every shared object.

1. CREATE — where does the authoritative record originate?
2. GOVERN — where are changes to it controlled?
3. CONSUME — which systems need enough of it to carry out their responsibilities?

These rows are illustrative. The exercise matters more than the answers: a buyer who can fill this table for their own organisation can brief an implementation team in an afternoon.

Context Projection and Minimum Necessary Integration

Integration should project the part of another system's truth that is needed to make the local decision — no more.

The ERP may know that bearing 6208-2RS has a quantity available of four, a unit cost of $126, a storage location in Central Stores, a supplier, a purchasing history and a set of valuation details. To decide whether WO-8471 can proceed on Tuesday, maintenance needs the correct part identity, whether it fits, how many are available, where they are, whether enough are free for this job, and the relevant cost.

The reverse holds too. The ERP does not need the technician's narrative, the vibration readings, every maintenance finding or every procedure step in order to post an expense correctly.

• Fewer mappings to build and maintain
• Fewer points where an exchange can fail
• Less data exposed across a security boundary
• Simpler governance when a field definition changes
• Testing that a human being can actually complete
• Lower risk every time either system is upgraded

Synchronisation is not orchestration

Two very different things get described with the same sentence — “we integrate with ERP.”

Delaware's transportation department, scoping the replacement of its Maximo environment, described its current integration in exactly synchronisation terms: nightly batch import, once a day, mostly one way, with the stated goal to keep data in sync, exchanging work orders, assets, locations, companies, people and labour. That is a legitimate architecture. It is also plainly not an orchestrated procurement process, and a buyer should know which one they are being shown.

The orchestrated version looks different on paper. It is specified object by object, with a direction for each one.

Spokane Transit's interface table for its EAM procurement names the Tyler ERP interface as two-way and real-time, then lists what moves in each direction. From the ERP to the EAM: staff time cost, materials cost, equipment cost, contractor invoices, staff certifications and training, vendor information, the item master list, purchase order status and a new asset list. From the EAM back to the ERP: staff hours spent on work orders, equipment hours, materials used, purchase requests, materials receiving status and item master list updates. Read that list again as a design document rather than a requirement. Purchase order status flows down because a planner needs it. Purchase requests flow up because maintenance originates the demand but does not own the purchase.

Ask whether the integration synchronises records, orchestrates a process, or does both.

Preserve the causal chain

Follow the bearing all the way through. The chain runs from the asset through the work order to the financial posting.

P-104 failure → WO-8471 → material demand → requisition 7911 → PO 28417 → receipt → bearing issue → repair → invoice → financial posting

This is not a collection of records. It is a causal chain. Every link exists because the previous link happened.

If the transactions survive but the relationships between them disappear, finance ends up knowing that the organisation spent $1,015 with a supplier, and maintenance loses the fact that it spent $1,015 because P-104's bearing failed. Both halves are accurate. Together they no longer explain anything.

This does not mean every system needs every record. It means the relationship must remain reconstructable by a person who was not there when it happened.

The Forward-and-Backward Trace Test

Hand the vendor a complete chain — P-104, WO-8471, a requisition, a PO, a receipt, a bearing installation and an invoice — and give two instructions in sequence.

• Show us the chain from P-104 to the financial consequence.
• Now start from the invoice and show us why the organisation spent this money.

Watch what the demonstrator has to do. Exporting spreadsheets, searching IDs by hand, inferring relationships from free-text descriptions, or leaving the system repeatedly are all findings. The test is about traceability across a boundary, not about forcing every record into one product.

Cost has a lifecycle

A maintenance cost is not born as a final financial actual. It passes through states, and the number on a dashboard belongs to one of them.

ESTIMATED → COMMITTED → RECEIVED → INVOICED → FINANCIALLY RECOGNISED

Running alongside the cost state is a separate dimension: maintenance-attributed cost, meaning the portion of the economic consequence associated with P-104, with WO-8471, or with some other maintainable object. The two dimensions intersect without being the same thing.

When the dashboard says this asset cost $48,312 last year, which cost state is that?

Cost provenance and cost lineage

Provenance asks where a value originated: a labour estimate, an inventory issue, a supplier invoice, a contractor charge, an ERP actual. Lineage asks how the value changed as the process progressed.

A single precise figure without lineage creates false precision. Someone reading $1,015 cannot tell whether that number has finished moving.

The maintenance cost boundary

When anyone says asset maintenance cost equals a number, ask what is inside the boundary.

• Internal labour, and whether overtime is treated differently
• Stock materials and non-stock materials
• Contractor and outside-service charges
• Freight and tax
• Tools and rental equipment
• Allocated overhead
• Downtime or lost production
• Capital work performed on the same asset

Comparable cost requires comparable cost boundaries.

There is no universal definition to adopt. There is only the discipline of writing down which components are included before comparing two assets, two plants or two years.

The operational clock is not the financial clock

The technician finishes P-104 on Friday afternoon. Physically, the work is complete. The contractor's invoice has not arrived, an invoice variance is unresolved, and month-end posting has not run.

Maintenance complete is not the same as financially complete.

A Monday maintenance report may legitimately show provisional operational cost while finance still holds a different figure. Neither is wrong if the meaning attached to each number is clear to whoever is reading it. The failure is when a dashboard presents a provisional number in the same typeface as a closed one.

Financial correctness is not maintenance attribution

The ERP posts $1,015 to maintenance expense for Plant 4. Accounting is correct. Plant 4 contains three hundred maintainable assets.

If the relationship back to P-104 was never carried or was lost in transit, the organisation has a clean ledger and no maintenance intelligence. The reverse failure also happens: the CMMS attributes $1,015 to P-104 accurately while the ERP posts it to the wrong cost centre. Maintenance intelligence can be right while financial control is wrong.

The boundary must preserve both dimensions. Correct in one system is not correct overall.

Transaction state is not data sync

Maintenance rarely needs the ERP's data. It needs the ERP's state. A planner deciding whether WO-8471 can be scheduled needs to know whether the request is requested, approved, rejected, ordered, backordered, partially received, fully received or cancelled.

Synchronising a PO number communicates almost none of that. The number tells the planner a purchase exists. It does not tell them whether work can proceed.

The purchase order belongs to procurement. Its operational consequence belongs to maintenance.

The ready-to-work problem

Even “received” does not automatically mean ready. A received part may sit at another warehouse, arrive partially, be quarantined pending inspection, be allocated to a different job, or turn out to be the wrong revision.

The useful question is not whether inventory data integrates. It is whether maintenance receives enough enterprise state to make the correct operational decision at the moment the decision is made.

Padre Dam Municipal Water District, procuring a CMMS for the East County Advanced Water Purification project, wrote the requirement in operational terms rather than technical ones. Its Tyler MUNIS ERP is expected to support purchasing and inventory management, and the district asks for CMMS integration with MUNIS inventory to maintain a synchronised list of spare parts and materials for assignment to assets and work orders, including available item quantities and accurate costs. The reason given is the one that matters: availability of critical spare parts is essential for minimising downtime when an asset fails.

Operational State Integrity

False positive state

The CMMS says a technician can act when reality says they cannot. The CMMS shows the part as available while the ERP has allocated it elsewhere. The CMMS shows the PO as submitted after the ERP rejected it. The CMMS shows the job as ready when the part has not arrived.

False negative state

The CMMS says a technician cannot act when reality says they can. The ERP received the critical part at 9:00 AM; nightly synchronisation means the CMMS still shows it unavailable at 2:00 PM, and a planner defers work that could have been done.

Does the maintenance system's representation of enterprise-dependent conditions remain trustworthy enough to operate from? That is the evaluation question.

Synchronisation urgency

Not every interface needs to be real-time, and buyers are frequently sold latency they do not need.

Integration frequency should follow decision urgency, not technology fashion.

The question to ask about each object is simple: how stale can this information become before somebody makes the wrong decision?

These bands are illustrative, and urgency varies by operation. A continuous process plant in an outage and a facilities team on a five-day planning horizon are not the same problem.

Public buyers reason this way in writing. Asked what latency it would tolerate for real-time interactions, Spokane Transit answered no more than five minutes, and gave the reason: the data is needed for operational awareness, not instant control. Tacoma Public Utilities went the other direction for its CMMS, stating that batch notification and processing is sufficient and that real-time streaming is not required. Two defensible answers, each tied to what the decision needs.

Error handling and reconciliation

Most integration diagrams show two boxes and a double-headed arrow. The arrow is where the real work is, because the arrow sometimes fails.

Start with the simplest disagreement. The CMMS shows seven bearings on hand. The ERP shows five.

• Which system is authoritative for this object?
• Does one side automatically overwrite the other?
• Does the conflict enter a review queue instead?
• Who owns that queue, by name and role?
• Can a user see why the two values differ?
• Is the correction recorded and auditable?

Technical errors should become operational exceptions

A middleware log entry reading “HTTP 422 — invalid dimension code” is useful to an integration engineer and useless to a maintenance planner who is deciding whether to send a crew.

The planner needs something intelligible: the purchase request was not accepted by the financial system and planner action is required. Same failure, translated into the language of the person whose decision depends on it.

A trustworthy integration makes business-process failures visible to the people whose work depends on them.

Four failure tests to run in a demo

The Rejected Requisition Test

P-104 needs a bearing. The CMMS creates the material demand. The requisition crosses to the ERP. The ERP rejects it because the cost centre is invalid.

Ask what the maintenance planner sees, and when. The dangerous outcome is a CMMS that still reads “part ordered” while the ERP holds a rejected requisition.

The Lost Confirmation Test

The CMMS sends an instruction to issue one bearing. The ERP processes it. The network response fails before the CMMS receives confirmation, so the CMMS retries.

Ask plainly: how do you prevent the ERP from posting that issue twice? A buyer does not need the engineering vocabulary for this. They need to know that the vendor has an answer, that it has been tested, and that a duplicate posting would be detected rather than quietly inflating the cost of P-104.

The Partial-Posting Test

WO-8471 sends labour, materials and contractor cost. The ERP accepts labour and materials and rejects the contractor cost.

• What does the CMMS show — is the work financially complete or not?
• Who sees the failure, and in which system?
• Can the failed component be retried on its own?
• How do you avoid reposting the two components that already succeeded?
• Can the discrepancy be reconciled and closed?

This single scenario tests integration maturity far better than asking whether the product has an ERP API.

The Month-End Test

The CMMS reports labour of $1,200, materials of $3,600 and contractor cost of $4,000, for a total of $8,800. Finance later reports $10,150 for the same period.

Neither number is automatically wrong. The gap can be freight, tax, invoice variance, inventory valuation method, labour burden treatment, an outside-service adjustment, a late invoice, an accrual, a credit or allocated overhead.

• Which number should be used for which decision?
• Can a user see the difference explained rather than merely observe it?
• Does the maintenance figure update when the invoice variance resolves?

The Six-Part Integration Boundary

For every handoff between CMMS and ERP, define six things.

Object → Authority → Trigger → State → Timeliness → Exception

Six rows per object, one table for the whole interface. It is short enough to complete in a workshop and specific enough to hand to an implementation partner.

The Bearing Test

This is the centrepiece of a vendor evaluation. Give the vendor one sentence and then add complications one at a time.

P-104 fails at 2:00 AM. The required bearing is not in stock. Walk us from the maintenance need all the way through purchase, receipt, installation, work completion and financial recognition.

1. Need — the technician identifies the bearing. Where is the material demand created?
2. Availability — which system determines stock availability, and how current is that information at the moment the planner reads it?
3. Request — who creates the requisition, and what maintenance context travels with it?
4. Approval — where does purchasing authorisation happen, and does maintenance see the approval state?
5. Rejection — the ERP rejects the request because the cost centre is invalid. What does maintenance see, and how soon?
6. Purchase order — which system owns the PO, and what information returns to maintenance?
7. Partial receipt — the supplier ships one of two bearings. What state does the CMMS show, and can the planner tell whether work can proceed?
8. Lost confirmation — an integration response is lost. How is duplicate posting prevented?
9. Material issue — the technician installs one bearing. Who owns the inventory decrement, and how is the consumption attributed to P-104 and WO-8471?
10. Work completion — labour and material are captured. What closes operationally, and what remains open financially?
11. Invoice variance — the invoice arrives at $1,015 rather than $920. Which cost changes, in which system, and when?
12. Month-end — what cost does P-104 show before financial close, what does it show afterward, and can a user tell the difference?
13. Reconciliation — the two systems disagree. Who finds out, and how is it resolved?
14. Audit — six months later, reconstruct why this money was spent. Trace P-104 → work → demand → purchase → receipt → installation → invoice → financial actual, then run it backward.

A vendor who can carry this scenario end to end has demonstrated more than any integration checklist will capture. A vendor who cannot has told the buyer exactly where the manual work will land.

Four architecture patterns

There is no ranking here. Each pattern has a characteristic strength and a characteristic risk.

A shared database can remove an interface without removing the handoff.

Separate systems are not automatically bad

A separate CMMS alongside an ERP can be an excellent architecture when authority is clear, identities are mapped, interfaces are reliable, operational states are visible, exceptions are managed, costs reconcile, and users are not retyping the same transaction in two places.

The same platform is not automatically good

A shared suite may remove technical interfaces and still require ownership decisions, workflow design, permissions, master-data governance, cost attribution rules, state transitions and organisational handoffs between maintenance, stores, purchasing and accounting.

The API boundary may disappear. The business boundary remains.

Architecture quality depends on boundary design, not on the number of products.

The Native ERP Maintenance Test

“Our ERP already has maintenance” deserves a test rather than a dismissal. Give the ERP maintenance module the same scenario a standalone CMMS would receive, for P-104, and watch all of it.

• Asset history and configuration
• Failure capture and coding
• Work planning and job plans
• Maintenance procedures and safety information where relevant
• Material requirements and inventory availability at planning time
• Scheduling and resource assignment
• Mobile execution in the field
• Technician findings and narrative
• Follow-up work generation
• Cost attribution back to the asset
• Preventive maintenance implications of what was found
• The maintenance history this leaves behind for the next decision

Then put real maintenance users in front of it, not the finance team. Public buyers reach both conclusions honestly. Tacoma Public Utilities stated that while SAP provides strong functionality for enterprise-level operations, it does not fully meet its power generation group's needs for managing maintenance activities, asset performance and work order tracking, and that a CMMS would complement the existing ERP. That is a considered judgement about one organisation's operating model, not a general verdict on ERP maintenance modules.

If the ERP module handles the operating model well, the organisation may not need a separate CMMS at all. If it technically contains the functions but makes maintenance execution slow or awkward, that matters too — an unusable module produces the same outcome as a missing one.

Padre Dam's procurement illustrates how this judgement actually lands. Its MUNIS environment includes general ledger, accounts payable, accounts receivable, procurement, inventory, fixed assets, budgeting, timekeeping, payroll and a work orders module. The district still went to market for a CMMS, and specified integration back to MUNIS for fixed assets, inventory, labour and parts and material costs. The presence of a work orders module in the ERP did not settle the question. The operating model did.

Integration debt

Every manual bridge between two systems is a place where meaning can be re-entered, delayed, duplicated, altered, misclassified, lost or never reconciled. Those bridges accumulate. Each one seems reasonable when it is created.

• Maintenance cost visibility that nobody quite trusts
• Inventory figures that are right in one system and wrong in the other
• Reporting assembled by hand every month
• Weak visibility of what maintenance has on order
• The same transaction typed into two systems by two people
• Lifecycle information disconnected from the work that produced it
• Departments that disagree about basic facts and have no way to settle it

Spokane Transit's procurement records an ordinary version of this: asked whether it held the Tyler ERP API set for integration work, the agency answered that it does not yet have it and will acquire it for the initiative. Integration capability is not automatically present because two systems exist in the same organisation.

Buyer questions

Ownership

Answer these as a table, one row per object, before any demo.

• Which system owns work orders, and which owns preventive maintenance?
• Which owns the vendor master?
• Which owns the part master, and which owns quantity on hand?
• Which owns inventory valuation?
• Which owns requisitions, purchase orders and receipts?
• Which owns invoices, GL accounts and cost centres?
• Which owns financial assets, and which owns maintainable assets?
• Which owns maintenance findings and failure history?

Asset identity

• Does the financial asset hierarchy differ from the maintenance hierarchy, and how are the two related?
• Can one financial asset map to several maintainable objects?
• What happens when equipment is replaced but the financial or project structure changes differently?
• Can the historical relationship survive retirement of either record?

Integration

• What objects cross the boundary, and in which direction?
• Is each exchange synchronisation, orchestration, or both?
• What triggers each exchange?
• What status comes back, and to whom is it visible?
• What is the expected latency for each object?
• What happens to operations when the interface is unavailable for a day?

Exceptions

• How does maintenance learn that a requisition was rejected?
• How are integration errors surfaced to operational users rather than only to IT?
• How are retries handled, and how are duplicate transactions prevented?
• How are partial successes handled and retried without reposting what worked?
• Who owns reconciliation, and is there an exception queue with a named owner?
• Are corrections auditable after the fact?

Cost

• Which costs shown in the CMMS are estimates, which are committed, and which are financial actuals?
• When do actual costs return from the ERP, and does the display change when they do?
• Can a user see where a cost figure came from?
• Can an invoice variance update the maintenance cost on the asset?
• What is included in “asset maintenance cost” in this configuration?
• Can two assets be compared on the same cost boundary?

Timeliness and user experience

• Which objects require near-real-time exchange and which can safely be scheduled?
• How stale can inventory availability and PO status become before a planner is misled?
• What happens operationally when the integration falls behind?
• Does a technician have to understand ERP accounting structures to complete a work order?
• Does finance need maintenance-system expertise to understand a posting?
• Can each department work in the language of its own responsibility?

What to take into a vendor evaluation

Bring three artefacts. First, a completed ownership table — one row per shared object, with create, govern and consume filled in. Second, the Six-Part Integration Boundary applied to the five or six objects that matter most in your operation. Third, the Bearing Test, written as a scenario with your own asset, your own part and your own approval thresholds, the same way you would build any structured requirements set.

Run the same scenario against every option, including an ERP maintenance module and a standalone maintenance management product. The comparison only means something if the scenario is identical.

Don't ask whether the systems integrate. Ask what crosses the boundary, who owns it, what state comes back, how quickly it must return, and what happens when it fails.

Related reading

Where maintenance ends and lifecycle, risk and capital decisions begin is the subject of CMMS vs asset management software. The difference between maintenance continuity and work control is covered in CMMS vs work order software, and the CMMS and EAM overlap is covered in CMMS vs EAM.