SAP business processes and document flow

• Procure-to-pay: requisition → PO → goods receipt → invoice → payment.
• Order-to-cash: sales order → delivery → billing → receipt.
• Plan-to-produce: demand → MRP → production order → confirmation.
• Record-to-report: postings → period close → statements.
• Hire-to-retire: the employee lifecycle.

Each process spans several modules and always touches finance. Procure-to-pay is mostly MM but posts to FI at goods receipt and invoice. Order-to-cash is SD but bills through FI. Learning where these hand-offs happen is where real understanding lives.

Every one of these processes is a chain of documents, each referencing the one before, and that chain is the most useful thing in SAP for anyone doing support or analysis.

In procure to pay it runs requisition, purchase order, goods receipt, invoice, payment. In order to cash it runs sales order, delivery, goods issue, billing document, incoming payment. Each step copies data from its predecessor and adds its own, and each is a separate document with its own number.

Two consequences follow. First, a question about what happened is answered by reading the chain rather than by asking people. Second, a value that looks wrong at the end usually entered at a specific step, and the chain tells you which.

Learning to read a document flow in both directions, forward from an order and backward from an accounting document, is worth more early on than memorising any individual transaction. See SAP navigation for how to move around while doing it.

Half an hour, and it is the exercise that turns a list of modules into a picture.

1. Find a completed sales order in a practice system, or create one and process it through delivery and billing.
2. Open the order and display its document flow. Note that every later document appears, with its status.
3. Open the accounting document at the end. Ask yourself which step created each line: the goods issue produced the cost of sales entry, the billing document produced revenue and receivables.
4. Now go backwards. From the accounting document, find the billing document, then the delivery, then the order.
5. Do the same for a purchase order using its history tab.

Once both directions feel natural, most support work becomes tractable, because the first question is always where in the chain this went wrong.

When you configure SAP, you are shaping how a process runs, which document types, which approvals, which account determinations. Keeping the end-to-end process in mind stops you from configuring one step in a way that breaks the next.

This is why configuration is taught by process rather than by screen. Deciding that a sales order of a certain type creates a certain delivery type, which allows a certain billing type, is a chain of settings that only makes sense if you can see the chain of documents it produces. See SAP Business Partner for the master data every one of these documents refers to.

• Fit to standard or fit to the business. The strongest projects change the business where the standard process is sound and change the system only where the business genuinely differs. The weakest rebuild the old system in a new one.
• Where control points sit. Approvals, credit checks and quality holds each stop a process, and each needs an owner who releases it. A control with no owner becomes a bottleneck nobody can clear.
• How exceptions run. Returns, cancellations, partial deliveries and short payments are not edge cases, they are daily, and a design that only handles the happy path fails in week one.

The reason finance keeps appearing in descriptions of logistics processes is that every one of them ends there, and knowing the exact moment each posts is worth more than knowing the steps.

In procure to pay, ordering posts nothing. The goods receipt is the first accounting document, because stock now has value. The invoice creates the liability, and payment clears it. So a purchase order with no accounting document is not an error, it is the design.

In order to cash, the sales order posts nothing either. Goods issue reduces inventory and posts cost of sales. Billing posts revenue and the receivable. Cash application clears it. Revenue is recognised at billing rather than at order, which is why a large order book is not income.

In plan to produce, component issues and confirmations accumulate cost on the production order, the goods receipt of the finished item values it into stock, and settlement at period end moves the variance where it belongs.

The pattern is consistent: intention posts nothing, movement of value posts something. An order is an intention. A goods movement, an invoice or a payment moves value. Once that is clear, the question of whether a step should have created an accounting document stops being guesswork.

It also explains why finance people ask logistics questions. If revenue is wrong, the billing document is wrong, and if that is right, the delivery behind it is wrong. See the company code for the organisational unit all of it posts into.

Every process description shows the path where nothing goes wrong. Almost no working day looks like that, and the exceptions are where configuration effort actually goes.

In procure to pay: the delivery is short, the invoice does not match, the supplier sends goods nobody ordered, the price changed after the order. Each has a document type and a set of tolerances behind it.

In order to cash: the customer returns goods, disputes an invoice, pays part of it, or is blocked for credit halfway through. Each stops the flow at a different point and needs somebody with the authority to release it.

In production: the order is confirmed with the wrong quantity, a component is short, the operation is scrapped. Each leaves cost somewhere it should not be.

Two questions are worth asking of any process design. What happens when this step fails, and who is responsible for clearing it. A design that answers both survives contact with a real business, and one that answers neither produces a queue nobody owns.

• Learning screens in isolation instead of the flow.
• Ignoring the finance integration in every logistics process.
• Configuring one step without the next, breaking the hand-off.

• Learning transactions as a list. A transaction memorised without its place in a process is forgotten by the following week.
• Ignoring the reverse direction. Finance meets these processes at the end, and being able to walk backwards from a posting is what makes you useful to them. See the SAP GUI if the navigation itself is still new.

• Designing for the process the business describes rather than the one it runs. Ask to watch somebody do it. The described version leaves out the exceptions, and the exceptions are where the configuration effort goes.

Reading a process is the start, and configuring the document types and control points that make one run correctly is the part you do in the course.

The single most useful thing on this page is the rule that intention posts nothing and movement of value posts something. Applied to any process, it tells you which step should have created an accounting document, and therefore where to look when one is missing.