SAP use cases: where processes hand off

The process definitions are in SAP business processes and document flow. This lesson follows what happens at the handoffs, where one module's document becomes another module's posting.

• Procure-to-pay: requisition → purchase order → goods receipt → invoice → payment (MM + FI).
• Order-to-cash: sales order → delivery → billing → payment (SD + FI).
• Plan-to-produce: demand → MRP → production order → confirmation → stock (PP + MM).
• Record-to-report: postings → period close → financial statements (FI + CO).
• Hire-to-retire: the employee lifecycle (HCM/SuccessFactors).

The names themselves are worth knowing because they are the vocabulary of every project plan and every job advert. Procure to pay, order to cash, plan to produce, hire to retire, record to report and acquire to retire. Somebody scoping a programme will speak in these terms, and a consultant who answers in module names is answering a different question.

SAP’s power is that these processes are integrated: a goods receipt in procure-to-pay simultaneously updates inventory, financial accounting and controlling. Learning SAP by process, rather than by isolated screens, is how consultants actually think.

Each process is a chain, and the interesting points are where one function hands to another, because that is where an integrated system differs from separate ones.

In procure to pay: procurement hands to receiving when goods arrive, receiving hands to finance when the value posts, and finance hands to treasury at payment. The join that matters is the three-way match, which is only possible because all three documents live in one system.

In order to cash: sales hands to the warehouse at delivery, the warehouse hands to finance at goods issue, and finance hands to collections at invoice. The join is the availability check, which lets sales promise a date using warehouse data.

In plan to produce: planning hands to production at order release, production hands to inventory at goods receipt, and inventory hands to costing at settlement. The join is that the bill of materials drives both what is planned and what is costed.

In hire to retire: HR hands to finance at payroll posting and to controlling at cost assignment.

The general rule this reveals: the value of an integrated system is not in any one module, it is that the handoff carries data rather than being a re-keying exercise. And the incidents concentrate at exactly those points, which is why the people who can read a document flow across two modules are the ones who resolve them.

An hour, and it is the single most useful orientation exercise on a new system.

1. Find a completed sales order, or create one and process it through.
2. Open the document flow. Order, delivery, goods issue, invoice, accounting document.
3. At each step, ask which function performed it and what data it inherited from the step before.
4. Open the goods issue material document and its accounting document. Inventory fell and cost of sales posted, and neither was entered by anyone.
5. Open the invoice and its accounting document. Revenue and receivable, priced from condition records found at order entry.
6. Now do the same on a purchase order using its history tab.

By step six the abstraction has become concrete: the processes are chains of documents, each carrying the last one's data, and every module is one segment of a chain rather than a thing on its own.

Additional use cases include supply-chain planning (IBP), procurement networks (Ariba), analytics (SAC/BW), and industry-specific scenarios. All build on the integrated core.

Two more worth naming because they are common and often overlooked. Record to report is the finance process itself, from posting through close to statutory reporting, and it is the one every other process ends in. And acquire to retire covers fixed assets from purchase through depreciation to disposal, which is where capital spend lives. See deployment models for how these run in different editions.

• Scoping an implementation. Scoping by module produces gaps at the handoffs. Scoping by process makes the handoffs explicit and is why fit-to-standard workshops are run process by process.
• Choosing what to learn. A module learned without its neighbours leaves you unable to explain where your postings came from or went.
• Designing controls. The three-way match, credit checks and release strategies all sit at handoffs, because that is where a check is meaningful.
• Diagnosing incidents. The first question is which step of which chain, which narrows the search before anybody opens configuration.

The four core processes are universal in shape and differ enough in practice that recognising the variation is useful.

In discrete manufacturing, plan to produce is the dominant process, built on bills of material and routings, with production orders per batch.

In process industries the same process uses recipes and process orders, with batch management and quality inspection as requirements rather than options.

In retail, procure to pay dominates and looks different: buying assortments rather than materials, allocating to stores, and a scale of transaction volume that changes how everything is designed.

In services, there is no plan to produce at all. The equivalent is project or service delivery, where the billable unit is time and expenses, and order to cash runs through project billing rather than through deliveries.

In utilities, order to cash is replaced by a metering and billing process the standard sales process has no concept of.

The practical instruction: when joining a project, ask which of the core processes is the one the business lives on. It is the one that gets the design attention, and the others are configured to support it.

The most practical use of this page is as a curriculum rather than as a description.

Pick one process and follow it completely. Order to cash is the usual first choice because it is visible and every business has one. Learn every document in the chain, what each one carries and what it triggers.

Then learn the finance end of it. Where goods issue posts, where billing posts, what the accounting documents contain. This is the step most people skip and it is what makes you able to talk to finance.

Then learn one adjacent process. Procure to pay, because it shares the three-way match idea and the same master data discipline.

Then go deep in one module inside those processes, which is what an employer actually hires for.

The reason for that order is that a module learned first is a set of screens, and a module learned after its processes is a set of decisions. It also means that when an interviewer asks something outside your module, you can answer it, which is frequently the question that distinguishes candidates.

• Learning screens in isolation instead of end-to-end processes.
• Ignoring the FI integration that underlies every logistics process.
• Missing hand-offs between modules, where most real issues occur.

• Learning modules as a list. A module without its place in a process is a set of screens.
• Assuming the process runs as described. Ask to watch somebody do it; the described version omits the exceptions, and the exceptions are most of the work.
• Treating finance as the end rather than as a participant. See the ecosystem, editions and how SAP evolved for the wider context.

Recognising the processes is the start, and configuring one end to end so its handoffs carry the right data is the part you do in the course.

The order that works when learning: one process end to end, then its finance end, then an adjacent process, then depth in one module. A module learned first is screens; a module learned after its process is decisions.