Why ERP Implementations Fail: Early Warning Signs in Purchasing and AP

ERP projects usually don’t fail on go-live day. Go-live is often the best week you’ll have. The project team is everywhere, everyone is paying attention, and the process is as clean as it’s going to get. The trouble starts a few weeks later, when the business resumes full speed, and the process has to hold up without a war room.

The Hershey story still gets talked about almost 30 years later. Imagine spending a $100 million on an ERP implementation just to have the system malfunction before your Halloween shipment. Most companies won’t have a headline moment like that, but the failure mode is the same: an ERP implementation is as much an operating model change as a software change, and when scope, data, and governance aren’t nailed down early, the rollout produces a system that is technically live but operationally unstable.

If you’re reading this, you’re probably trying to figure out three things: why ERP implementations often fail, how to spot trouble early, and what “working” actually looks like when you expect the ERP to handle purchasing and AP end-to-end.

Why ERP implementations fail

ERP implementations fail because an ERP only works as well as the decisions that get into it, and ERPs don’t control how those decisions are made.

An ERP is great at recording the financial result. It can post bills, track payments, and produce accurate reporting. Where implementations start to fall apart is earlier in the chain, when the organization needs consistent inputs across teams before money is committed.

That’s the part many companies assume the ERP will “handle,” but it’s not something the ERP can solve on its own.

It requires a shared, repeatable way of capturing the basics every time:

• who requested the purchase
• who approved it (and under what policy)
• what was ordered
• whether it was received
• how it ties back to budget and coding

In practice, those steps aren’t enforced consistently by the ERP. Different teams use the system in different ways, and not every purchase goes through the same sequence of request, approval, order, receipt, and validation. By the time an invoice reaches accounts payable, some of that information may be missing, incomplete, or stored elsewhere. Finance can still post the transaction, but has less clarity about why the spend happened and whether it followed policy.

That’s why ERP implementations are often labeled failures. The ERP is functioning from an accounting perspective, but the implementation doesn’t produce the consistent purchasing and AP process the organization expected.

How to tell if your ERP implementation is failing

If you want a real signal of ERP implementation failure, look for these patterns:

• Approvals are happening in email, chat, or hallway conversations because the ERP approval flow is too slow or too heavy for routine work
• Purchasing intake is inconsistent, which means request quality depends on who is asking and how much context they remember to include
• Purchase orders are created for some spend but not others, which turns “PO compliance” into a negotiation instead of a control
• Receiving is incomplete or skipped because the people receiving goods and services don’t live in the ERP and the step isn’t embedded in their day
• Invoices arrive without the chain of context (request → approval → PO → receipt), which makes three-way matching a manual process instead of a control
• Vendor and coding cleanup increases over time, which is usually a symptom of fragmented workflows and disconnected master data
• Month-end close does not get faster after go-live, and the team spends more time chasing missing approvals and reconstructing why spend happened

These aren’t edge cases. They’re early signs that the ERP is live, but the implementation isn’t producing a consistent process around purchasing and AP. When that happens, the organization ends up managing spend after the fact instead of having a reliable way to control company spending before it’s committed and maintain spend visibility across teams.

Where ERP failures show up first: procurement and accounts payable

Purchasing and accounts payable are where ERP implementations get stress-tested first, because this is where spend decisions turn into financial transactions. If the chain of information isn’t reliable here, finance feels it immediately.

These workflows have three traits that make problems surface fast: high volume, lots of handoffs, and a need for traceability. A single purchase can touch multiple people (requester, approver, buyer, receiver, AP), and each handoff is a chance for details to get lost or handled differently. When that happens, AP can’t validate quickly and finance can’t rely on the process to enforce policy before spend hits the books.

So when teams say “the ERP implementation is failing,” what they often mean is that purchasing and AP never became consistent enough to produce clean, explainable spend—not that the ERP can’t do accounting.

Should you customize your ERP to fix it?

You can, and sometimes basic configuration is the right thing to do. The risk starts when customization becomes the main way to make purchasing and AP workflows usable.

Most heavy ERP customization begins with good intentions. Teams add steps, rules, validations, routing logic, and automations to make the process reflect how the business actually operates. The problem is that purchasing process and AP policies change frequently. Approval thresholds shift, org structures change, categories evolve, and exception paths multiply. Every layer of custom workflow logic becomes something you now have to maintain, test, and update as the business changes.

Customization also doesn’t guarantee adoption. If a workflow is slow, confusing, or too rigid for real-world exceptions, people will find workarounds. That’s how organizations end up paying twice: once for customization, and again in the form of parallel processes and cleanup work.

A more sustainable approach is to keep customization focused on what the ERP is designed to do well—controls, data integrity, and financial posting, then connect operational workflows through procure-to-pay integrations rather than turning the ERP into the primary workflow tool for everyone.

What good ERP integration looks like

“Integrates with your ERP” can mean almost anything, so it’s worth being specific about what good integration actually delivers.

At a basic level, good integration means you don’t have two systems that both kind of own the same thing. The ERP stays the source of truth for accounting. The workflow system handles the operational steps. Integration is what makes that division feel like one process instead of two disconnected tools.

A good integration keeps four things true:

1) One source of truth for master data

Vendor records, chart of accounts, departments, locations, classes, projects—whatever your organization uses to code spend—shouldn’t drift. You shouldn’t be fixing duplicates, remapping codes, or debating which system is “right.” If master data is changing, it should change in one place and sync cleanly.

2) Context travels with the transaction

When a purchase is approved, the important context shouldn’t disappear at the handoff. The ERP may only need the final coding and totals, but AP and finance often need more to validate quickly: what was approved, by whom, what it was for, and what changed. Good integration preserves that trail so invoices don’t turn into detective work.

3) Sync rules are clear and changeable

The workflow will evolve. Approval limits change. New categories show up. The organization restructures. Good integration has explicit rules (what syncs, when it syncs, what happens on updates) and those rules can be adjusted without turning into a rebuild or a brittle custom project.

4) Exceptions are handled as a first-class part of the process

Mismatches happen: pricing changes, partial receipts, split shipments, credits, duplicate invoices, late POs. Good integration doesn’t pretend exceptions won’t exist. It makes them visible, keeps ownership clear, and prevents exceptions from becoming spreadsheet work or inbox archaeology.

Why AP is where integration quality becomes obvious

You usually feel integration quality first in accounts payable because AP sits at the moment where “work happened” has to become “financially valid.” If the purchasing trail is incomplete, if coding doesn’t line up, or if the system handoff drops context, AP pays for it in manual validation, messy audit trails, and longer close cycles. If integration is working, invoices move faster because the basics are already connected and verifiable. This is why AP and ERP integration matters so much.

ERP vs procurement workflow tools: what each should own

An ERP is built to be the system of record for finance. It’s where transactions are posted, controls are enforced, and reporting is produced. That’s the layer finance relies on for accuracy and auditability.

Procurement workflow tools (often grouped under procurement software or spend management tools) are the operational layer that feeds those transactions. They handle the steps before accounting: requests, approvals, purchase orders, receiving, invoice handling, and the context that explains why spend happened and whether it followed policy.

When these responsibilities are separated cleanly, the flow is straightforward: the workflow layer captures the decision and supporting context early, and the ERP records the financial outcome with the right coding and supporting trail. The ERP stays dependable for accounting, and the operational process stays usable for the teams who actually run it.

If you want to make that split easier to reason about, it helps to be clear on what procurement covers and what spend management means in practice.

What to review next if you already have an ERP

If your ERP is live, the most useful next step isn’t a new project. It’s a quick reality check on how spend actually moves through your process.

1) Walk one real purchase all the way through.

Pick a normal purchase (not a perfect example) and trace it end to end: request → approval → PO → receipt → invoice → posting. You’re looking for two things:

where the “trail” breaks (missing approvals, missing PO/receipt, missing coding, unclear owner)

where the work leaves the system (email approvals, side spreadsheets, manual handoffs)

2) Count how many paths exist for the same kind of spend.

Ask: for similar purchases, do different teams follow different steps? If yes, decide whether that variation is intentional (policy-based) or accidental (habit-based). The accidental version is where control and reporting get unreliable.

3) Identify where cleanup is happening.

Look at the last month-end close and ask where time went: chasing approvals, reconciling POs/receipts, fixing vendors/coding, explaining variances. That list tells you exactly which parts of the upstream workflow aren’t producing consistent inputs.

If you can run those three checks and clearly answer what’s happening at each step, you’ll know whether your ERP implementation is holding up in the parts that matter most—purchasing and accounts payable.

Next steps consider a vendor analysis and compare how different tools handle approvals, PO/receiving discipline, invoice matching context, exceptions, and how much maintenance the integration actually creates.