ERP for Beginners: Core Business Processes in ERP: O2C, P2P, Plan-to-Produce Explained

If modules are the map of an ERP, business processes are the routes people take across it. And it turns out there are really only three routes you need to know.

Order-to-Cash. Procure-to-Pay. Plan-to-Produce. Every ERP on the planet is built to run these three flows, because every business — regardless of industry — depends on some combination of them. Understanding these three is the difference between seeing ERP as a collection of features and seeing it as an operating system for the back office.

This is the fourth episode of our ERP for Beginners series, and it's where the pieces we've been assembling start to connect.

What is a business process?

First a definition, because the phrase gets overloaded. A business process in ERP terms is a chain of steps that starts with a real-world trigger, walks across several modules, and ends with a financial posting.

Those three characteristics matter. The trigger is always something in the outside world — a customer places an order, stock drops below a reorder point, a production forecast gets approved. The chain touches multiple modules — Sales talks to Inventory talks to Finance. And the endpoint is always a finance event, because no matter how many physical operations happen in the middle, the accounting books have to catch up at the end.

Modules alone can't run processes. Sales doesn't ship products; Inventory does. Inventory doesn't create invoices; Sales does. Procurement doesn't pay vendors; Finance does. The process is what stitches them together.

That stitching is the actual product ERP sells. Standalone modules existed before ERP — QuickBooks for accounting, specialised warehouse tools for inventory, CRM tools for sales. What ERP added was the glue between them, which is where the value lives.

Order-to-Cash — the revenue loop

The first of the three is Order-to-Cash, abbreviated O2C. Every business that sells anything runs a version of this. Customer orders something, we deliver it, we invoice them, they pay.

In practice, the flow walks across Sales, Inventory, and Finance. Quote — a customer asks for a price, and Sales responds. Sales order — the customer confirms and commits to buy. Pick and ship — Inventory reserves the stock, picks it from its bin, and sends it out the door. Invoice — Finance creates an Accounts Receivable entry; we're now owed money. Collect cash — when payment arrives, the receivable clears.

Five steps, three modules, one customer journey. Every step posts to Finance either directly or as a side effect. The sales order itself is usually a statistical posting (a plan, not actual money). The goods issue reduces inventory and creates a cost-of-goods-sold expense. The invoice creates the receivable. The cash receipt clears it.

O2C is the most visible process in any company because it's how revenue enters. When an ERP salesperson demos their product, the O2C flow is almost always the first thing they show. And when companies worry about "how our orders get from sales to billing", they're talking about making O2C smoother.

Procure-to-Pay — the spending loop

The mirror image is Procure-to-Pay — P2P. Someone inside the business identifies a need, we buy something to fill it, it arrives, we pay. Every business that buys anything runs this, which is all of them.

The steps walk across Procurement, Inventory, and Finance. Requisition — someone inside the business (a department head, a production planner) identifies a need. Purchase order — Procurement converts that into a formal commitment to the vendor. Goods receipt — when the shipment arrives, Inventory posts the receipt. Invoice verification — the vendor's bill arrives, and the system checks it against the PO and the GR using the famous three-way match (more on this in a moment). Payment — Finance clears Accounts Payable by transferring money.

The three-way match is the most important control in P2P. Before payment goes out, the system verifies that three things agree: the PO says how much was ordered at what price, the goods receipt confirms how much actually arrived, and the invoice shows what the vendor is billing. If any of the three disagree — the vendor ships less than ordered, or bills at a higher price, or the goods receipt is missing — the invoice gets blocked. Human approval intervenes before a dollar moves.

That's the whole point of P2P. Not the PO, not the goods receipt — the match. It's the safeguard against paying for things you didn't order or didn't get.

Plan-to-Produce — the making loop

The third process applies only to companies that actually make things. Plan-to-Produce — often shortened to P2Pr to distinguish it from Procure-to-Pay, which uses the same acronym — is the flow from demand forecast to finished goods.

This flow is the longest and most technically complex of the three. It walks across Planning, Manufacturing, Inventory, and Finance. Demand — a sales forecast or a stock minimum triggers a need to produce. MRP run — the planning engine explodes the bill of materials, checks what's already in stock and on order, and produces planned orders (make it) and purchase requisitions (buy it). Production order — a planner converts a planned order into a committed work order. Goods issue to production — raw materials leave the warehouse for the shop floor, reducing inventory and accruing cost against the production order. Confirmation — labour and machine time get recorded against the order. Goods receipt — finished goods post back into inventory at standard cost. Settlement — at period end, any variance between actual cost and standard cost posts to Finance.

If you're wondering why this is so much more complex than O2C or P2P, the answer is that making things is physically complex. You have to plan what to make before you make it, schedule machines and people, account for variance when reality doesn't match the plan. The software reflects the messiness of the factory floor.

Only manufacturers run P2Pr. A pure distributor buys finished goods and resells them — they run O2C (selling) and P2P (buying), but nothing like a full production process. A services firm might run O2C (selling hours) and P2P (buying laptops) but definitely not P2Pr. So when you see a Manufacturing module sitting quiet in an ERP for a pure services company, this is why — nothing's wrong, that flow just doesn't apply.

Why processes matter more than modules

Here's the thing I wish someone had told me years ago. When an ERP vendor talks about their product, they'll list modules — Finance, Procurement, Inventory, Sales. That's useful shorthand, but it misses what makes ERP worth buying.

The real value isn't the modules. It's what happens between the modules, automatically, when a business process walks across them.

Running a process inside one system rather than across ten buys you four practical things. Automation — one step completes, the next triggers, and nobody types the same number twice. Audit trail — every single step records who did it, when, and why, so a sales order traces all the way through to a bank deposit. Error detection — when something breaks at step three, the system catches it immediately, not in next month's reconciliation. And speed — the entire process moves at software speed, minutes and hours rather than days and weeks.

None of those benefits come from the modules individually. They come from the integration between them. A company running best-of-breed tools — a specialist CRM, a specialist WMS, a separate accounting package — can get excellent features in each one, but they can't get the end-to-end flow without building it themselves.

That's ERP's trade. You give up some specialist features. You get the process automation that gets a business from chaos to calm.

The thread that ties everything

If you take nothing else from this episode, take the process-first mental model. When you're looking at an ERP, don't think of it as a collection of modules. Think of it as the engine that runs three business processes — O2C, P2P, and (for manufacturers) P2Pr — and the modules are just the compartments those processes pass through.

That framing changes how you watch a demo. Instead of noting features module by module, you're tracking a single customer order or a single purchase as it walks the floor of the ERP, and you're paying attention to whether the handoffs between modules are clean or ugly.

Clean handoffs are where ERP earns its licence fee. Ugly handoffs are where companies end up typing things twice and debating whose number is right.

Episode five takes us to deployment — where the ERP actually lives. On-premise, public cloud, private cloud, hybrid. The tradeoffs behind the choice every customer eventually makes.