ERP for Beginners: Following a Transaction — One Sales Order, Every Module

In the first two episodes of this season we looked at two abstractions — customisation versus configuration, and master data versus transactional data. Both are mental models. Both are the kind of thing that sits in the back of your head when you're reading a spec or arguing about a scope change. They don't, by themselves, tell you what an ERP actually does minute to minute.

This episode is different. This one follows a single transaction from the moment someone types it into the system to the moment it shows up on a management report three weeks later. One sales order — where it starts, what modules it touches, what master data it pulls in, what records it spawns along the way, and how it ends up as a single number inside a quarter-end P&L. It's the thread that ties every module together, and once you can trace it by hand, everything else about ERP starts to make a lot more sense.

This is episode three of Season Two of ERP for Beginners — Going Deeper.

The shape of the story

Here's the arc we're going to walk. A customer calls up and places an order. Someone in the sales team keys the order into the ERP. Over the next few weeks, that single order quietly becomes six or seven linked documents, each living in a different module, each referencing the ones before it, each carrying a small additional piece of what ends up being a complete commercial event: goods moved, money owed, money received, books balanced.

In ERP parlance this chain is called the document flow, and every decent system has a feature to show it to you — one click on any document in the chain, and you see every sibling document forwards and backwards in the sequence. It's the cleanest single demonstration of what an ERP is actually for.

Step one — the sales order

It starts with the sales rep opening the sales order screen. They enter a customer, a delivery date, a material, a quantity. They hit save. That action, tiny on the surface, does a surprising amount of work behind the scenes.

The system looks up the customer master to find the ship-to address, the payment terms, the credit limit, the tax classification. It looks up the material master to find the standard price, the sales unit of measure, the tax code for that product. It looks up the pricing master to find any negotiated discount or currency conversion. It checks the credit management rules to see whether this customer is on credit hold. It checks available-to-promise against inventory to confirm the warehouse can actually deliver by the requested date.

All of that happens in the background of a single save. The output is one transactional record — a sales order document — with a new unique document number, and a status of open. That document is now the single source of truth for this commercial intent. Nobody else touches master data yet. Nothing has shipped. No money has moved. But a business commitment now exists in the system, and every downstream process will hang off the document number this step produced.

Step two — the delivery

Some days later, the warehouse runs the delivery process. They query the system for open sales orders due today, and the system returns a pick list. The warehouse staff go into the racks, pull the goods, and create a delivery document — sometimes called a delivery note, sometimes an outbound delivery, depending on the vendor.

The delivery document is a child of the sales order. It references the sales order number. It carries the quantity and material, but it adds warehouse-specific fields — the picking location, the batch number if the material is batch-managed, the shipping point, the carrier.

When the goods actually leave the warehouse, the warehouse posts a goods issue. This is the first financial event in the chain. Stock leaves the warehouse, cost of goods sold is posted to the general ledger, an inventory movement record is created, the material master's stock level is decremented. One save, many postings — and all of them trace back to the original sales order, which now shows a partial-delivered status.

Notice what's happened structurally: we now have three linked records. A sales order (commercial intent), a delivery document (logistics), and a goods issue (physical stock movement). Each references the one before it. Each was created by a different person in a different part of the business, probably in a different physical location. The only reason this coherence exists is the referential chain — the delivery points back at the sales order, the goods issue points back at the delivery.

Step three — the invoice

With the goods gone, the finance or billing team creates an invoice — sometimes called a billing document. This is where accounts receivable takes over from sales.

The invoice references the delivery document, which in turn references the sales order. The billing team doesn't re-enter the customer or the material or the quantity; the system derives all of that from the chain. What the invoice adds is the commercial finalisation — the price confirmed, the tax calculated, the payment terms applied, the document date and the due date.

Saving the invoice posts a set of entries to the general ledger. Accounts receivable is debited. Revenue is credited. Output VAT is credited to its tax account. The customer master now has an open item — a posted invoice waiting to be paid. The invoice itself gets a new document number, and the document flow now has four links in it.

Step four — the payment

Three or four weeks later, the customer pays. Their bank transfer hits the company's bank account. The finance team imports the bank statement, matches the incoming payment against the open invoice, and posts a payment document.

This is the first step in the chain that didn't originate in the sales process — it came from finance reconciling bank statements against open AR items. But because the payment is matched against the invoice, it joins the same document flow. Now the chain has five links. The invoice status flips from open to cleared. Cash on the balance sheet goes up. Accounts receivable goes down. The customer's open items list shrinks by one line.

Step five — the ledger and the report

The events we've described have, by this point, posted multiple lines into the general ledger. Goods issue posted COGS. Invoice posted AR and revenue and VAT. Payment posted cash and cleared AR. Each of these lines is a journal entry — a timestamped, audit-trailed record of a financial event, tagged with cost centre, profit centre, segment, or whatever other dimensions the organisation cares about.

When the CFO pulls up the management report for the quarter, those individual journal lines aggregate. The sales order you started this story with contributes to the revenue number on the P&L. The goods issue contributes to the COGS line. The difference — gross margin — was created by the very act of that order flowing through the system.

This is the moment the whole thing closes. What began as a sales rep typing into a screen ends as one numeric line in a management report. Every step in between was a document, linked to the ones before and after it by reference, each tied to a master record for its meaning, each producing its own set of postings to the central ledger. The ERP's job — the only job an ERP really has — was to keep every one of those links consistent.

The bigger idea

The single most useful mental model you can take away from this episode is the idea that an ERP is a document flow machine. Every business event, big or small, manifests as a linked chain of documents flowing across modules. Sales creates the order, logistics creates the delivery, finance creates the invoice, finance again creates the payment, accounting reflects every one of those events in the ledger.

The modules themselves — sales, logistics, AR, GL — are really just the different audiences of a single underlying chain. Each module is a specialised lens on the same set of facts. A sales rep sees the order. A warehouse manager sees the delivery. An AR clerk sees the invoice. A controller sees the journal. They're all looking at different sides of the same transaction.

This is why every production-grade ERP has a feature — Document Flow, Process Flow, Transaction Trace, whatever the vendor calls it — that shows you the whole chain from any starting point. It's the single most useful diagnostic in the system. If a customer disputes an invoice, you start at the invoice and walk backwards to the delivery, the sales order, the original commercial agreement. If a stock discrepancy shows up in a plant, you start at the inventory movement and walk backwards to the goods issue and the delivery and the order that triggered it. The chain is the audit trail.

Why this matters

For anyone new to ERP, the first instinct when looking at a module is to ask "what does this module do?" The better question, once you've seen how the document flow works, is "what's the upstream and downstream of this document?" Nothing in an ERP lives in isolation. Every transactional record is a link in a chain, carrying context from the documents before it and adding context for the documents that follow.

This is also why the two earlier mental models matter so much in practice. Customisation and configuration decide where the chain can go — which vendor's standard flow you're adopting, where you're choosing to deviate. Master data and transactional data decide what the chain is made of — master records provide the stable references, transactional records record the events. Once you see how a single order touches a dozen master records and spawns half a dozen transactional ones, the earlier episodes stop being abstractions and start being the bones of how the thing actually works.

What's next

That's following a transaction. One sales order, six linked documents, five modules, one management report. The document flow is the ERP's spine — it's what makes the system coherent instead of a heap of disconnected tables.

Episode four takes the opposite view. Instead of looking inside the ERP, we look at where the ERP ends — the boundary between ERP and every other system in the enterprise stack. CRM, warehouse management, BI, e-commerce, payroll SaaS. How ERP talks to the systems around it. Why integration is where most enterprise complexity actually lives.

See you there.