End-to-end process map

Each SAP module makes sense on its own, but interviews love the hand-offs: what one module passes to the next. Here is one customer order followed all the way through:

#	What happens	Module	Hands over to
1	Customer places a sales order	SD	PP: a requirement from the order’s schedule lines
2	MRP plans production and purchasing	PP	MM: purchase requisitions for components to buy
3	Purchase order goes to the supplier	MM	The supplier: it becomes their sales order
4	Components are received	MM	WM for putaway; FI: Dr Inventory / Cr GR/IR
5	Components are put away into a bin	WM	Production: stock ready to stage
6	Supplier invoice is matched	MM	FI: a payable, paid later by the payment run
7	Production consumes components	PP	FI/CO: costs collected on the production order
8	Finished goods are received	PP	SD: stock available to promise
9	Outbound delivery is created	SD	WM: a picking requirement
10	Goods are picked from the bin	WM	SD: picked quantities on the delivery
11	Goods issue posts	SD	FI: Dr Cost of goods sold / Cr Inventory
12	Customer is billed	SD	FI: Dr Receivable / Cr Revenue
13	Customer pays	SD	FI: the bank statement clears the receivable
14	Month is closed	FI	All modules’ postings meet in the financial statements

Read down the last column and you can see why SAP is called integrated: almost every step either creates work for another module or a journal entry in finance, automatically.

I built an interactive version of this map while working through the Global Bike case. Each stop shows the Fiori app and T-codes, the tables behind it, the stock and money impact, how automated it usually is in large companies, what goes wrong in real life, and, where I executed the step myself, my actual document numbers.

Open the interactive SAP process map →

The document trail

Tracing one order

From the sales order (VA03), the document flow shows the delivery, goods issue and invoice with their numbers and statuses. From the purchase order (ME23N), the purchase order history shows every goods receipt and invoice against it. Each material and invoice document links to its accounting document. Following these links answers most “what happened to this order?” questions without guesswork.

In the Global Bike exercises, document numbers follow typical number ranges: purchase orders starting 45 (4500000546), goods receipts 50 (5000000985), supplier invoices 51 (5105600427) and payments 15 (1500000157). Recognizing a document type from its number is a small skill interviewers notice.

What breaks at each hand-off

How much is automatic in large companies

• Planning: MRP runs nightly; planners work on exceptions, not on every material.
• Purchasing: approved requisitions with a valid source become purchase orders automatically (ME59N), and orders go to suppliers electronically.
• Receiving and invoicing: suppliers send advance shipping notices; invoices arrive electronically or are created by ERS; most match automatically.
• Payments and receipts: payment runs pay due invoices; electronic bank statements clear customer payments and supplier payments automatically.
• Sales: customer orders arrive by EDI or portal, are priced and checked automatically, and flow to delivery and billing with few touches.

People handle the exceptions: blocks, shortages, disputes and changes.

EDI messages

Electronic messages connect SAP with partners. Common ones: ORDERS (purchase order), ORDRSP (order confirmation), DESADV (dispatch advice or advance shipping notice) and INVOIC (invoice). In SAP they are exchanged as IDocs, which can be monitored and reprocessed when a message fails.

Bank statements

Electronic bank statements are imported daily and matched to open items using rules (reference numbers, amounts, customer IDs). Well-tuned matching clears most customer payments automatically and leaves only exceptions for the receivables team.

Process mining on SAP data

Because every step leaves a document with a timestamp, SAP data is well suited to process mining: reconstructing how orders actually flow, including rework loops (price changes after order creation, repeated credit blocks, invoice blocks) and variants nobody designed. The most common use is to find the few deviations that cause most delays and manual work.

Measuring the end-to-end flow

End-to-end measures come straight from document timestamps: order-to-delivery cycle time from the sales order to goods issue; procure-to-pay cycle time from requisition to payment; the share of invoices matched automatically; the share of orders processed without manual touches. Tracking them shows whether integration and automation are actually working.