Purchase-To-Pay (Purchasing for special-purpose machine manufacturer)

Note on this demo: All figures on this page come from a synthetic demonstration dataset. They illustrate analysis paths, business relationships and methods of Causal Process Mining. They are not production figures from any customer.

What is Purchase-to-Pay?

Purchase-to-Pay (P2P) describes the end-to-end process from the moment a procurement need arises to the payment of an invoice. In a special-purpose machinery manufacturer, the process typically covers purchase requisition and approval, purchase order and order items, physical or digital provisioning, goods receipt and inspection, as well as invoice, approval and payment.

On a process slide, this often looks linear. In the operational data, however, P2P is a network of interconnected business objects: a purchase requisition can trigger different approval logics, a purchase order can contain multiple items, physical goods and software follow different fulfillment paths, multiple goods receipts share inspection capacity, and invoices are related to the purchase order, goods receipt, terms and payment.

Noreja ingests this data at a granular level. Business objects, events, attributes and relationships are preserved and connected with each other in the Event Knowledge Graph. Only for a specific business question is the relevant process perspective derived from it.

 
Event Knowledge Graph of the Purchase-to-Pay process

At a Glance

The Process in Four Phases

The end-to-end perspective connects the parts of the shared process knowledge that are relevant to the business question. It reduces complexity for the process manager without losing the underlying object relationships.

 
End-to-end perspective of the Purchase-to-Pay process

Phase 1: Demand and Approval

A purchase requisition is created. Depending on value and procurement context, it can proceed directly or go through a multi-level approval path. Only then is the purchase order created.

Business objects: Purchase requisition, Approval A, Approval B, Purchase order, Requester, Cost center.

Typical flow: Purchase requisition created → Determine approval requirement → Approval A → Approval B → Purchase order created.

Guiding question: Are the approvals intended for this specific demand actually carried out?

Phase 2: Purchase Order and Fulfillment Path

After the purchase order is created, purchase order items are generated. The subsequent paths differ depending on the product group. Physical procurement requires delivery and goods receipt; software can be handled via provisioning.

Business objects: Purchase order, Purchase order item, Material, Supplier, Contract, Delivery, Software provisioning.

Guiding question: Which procurement path is intended from a business perspective for each item – and where do differences in lead time or behavior arise?

Phase 3: Goods Receipt and Inspection

Physical goods are inspected after receipt. Not every transaction is handled in isolation: many goods receipts share common inspection resources and are processed in bundled inspection runs.

 
Physical and software path up to the invoice

Business objects: Goods receipt, Goods receipt inspection, Inspection station, Inspection batch.

Guiding question: Is a transaction waiting because of its own flow – or because several transactions share the same resource and the same inspection run?

Phase 4: Invoice, Approval and Payment

Once the purchase order has been fulfilled, the invoice is recorded, approved and processed in the invoice run. Business deviations can trigger manual clarification or rework. For payment control, it is also relevant whether payment is made within the cash discount period.

Business objects: Invoice, Invoice approval, Invoice run, Payment, Supplier clarification, Cash discount period.

Guiding question: Which process conditions create rework, waiting time or a measurable financial effect?

Five Findings Along the Purchase-to-Pay Process

The following findings answer different business questions. What matters is not only what stands out, but why it happens, which conditions lie behind it and which lever can be derived from it.

Finding 1 · Compliance: The Fastest Path Is the Wrong One

1,145 requisitions requiring approval bypass the intended approvals. Not every process problem shows up as a delay. In procurement, a transaction can even be particularly fast precisely because necessary control steps are missing.

 
Maverick buying as the error pattern "Ignore"

In the current demonstration run, 1,145 purchase requisitions requiring approval lead directly to a purchase order. This corresponds to 26.3% of the requisitions requiring approval that were examined.

The Analyzer does not simply interpret the direct transition as an additional process variant. It classifies the behavior from a business perspective as ignoring an intended approval path.

On average, the direct path takes only around 15 minutes to reach the purchase order. The regular path through the intended approvals, by contrast, takes several hours. This is exactly where the business conflict lies: what looks attractive from a pure performance perspective is problematic from a governance and compliance perspective.

The fastest process path is not automatically the best process path.

From 1,145 Cases to a Concrete Root-Cause Hypothesis

The next step is to examine the affected business objects for common characteristics.

 
Attribute distribution of the maverick buying cases

Of the 1,145 affected cases, 597 are attributable to the requester Kaya and 515 to Braun. Together, the two account for around 97% of the visible maverick buying cases. Cost centers, by contrast, are distributed much more evenly.

This turns an abstract compliance finding into a concrete organizational hypothesis:

Why is the approval bypass concentrated in this group of requesters?

Possible explanations – such as authorizations, time pressure, local working practices or undocumented special rules – must then be validated by the business. The analysis narrows down the relevant population without inventing the organizational reason.

Instead of "Which variant is particularly fast?" the analysis asks: "Which control that is required from a business perspective is missing – and for which business objects is this behavior concentrated?"

Finding 2 · Invoice Processing: Rework Is a Symptom, Context Provides the Explanation

647 cases pass through visible rework loops. Long invoice lead times can result from waiting time, approval, clarification or genuine rework. That is why not only the duration is measured, but the observed behavior is classified as an error pattern.

 
Rework in invoice processing

Two visible rework loops comprise 554 and 93 cases respectively. Together, 647 cases are affected by repeated processing.

The statement "invoices are being reworked" is not yet sufficient for an improvement, however. What matters is why manual clarification becomes necessary.

Process Data Plus Business Context

In the demo, additional information from an IT/support ticket system was integrated into Noreja Context. Minerva can link the affected invoices to this business context via their invoice ID.

 
Minerva connects invoice rework with context from the ticket system

For the selected cases, this reveals concrete reasons for clarification: discrepancies between invoice and purchase order, unclear invoice line items, and price deviations from the stored terms.

This changes the statement from "invoices are being reworked" to:

"These business reasons trigger the rework."

This is crucial for deriving measures. Quantity or order discrepancies call for different countermeasures than unclear invoice line items or incorrect terms data.

Instead of "Where is the lead time long?" the analysis asks: "Which business inconsistency creates the rework – and which information outside the operational process data explains it?"

Finding 3 · Shared Capacity: When Multiple Transactions Share the Same Resource

Bundled goods receipt inspection creates cross-case dependencies. Goods receipt inspections are not viewed solely as isolated steps of an individual purchase order. Multiple inspections can be assigned to the same shared inspection run and therefore share the available resources.

 
Planned goods receipt inspections and shared inspection batches

This matters for root-cause analysis: an individual transaction can be correct from a business perspective and still wait because other transactions are claiming the same inspection slot.

The time perspective makes this logic visible. While purchase orders and goods receipts are created over time, the inspections actually carried out in bundles are concentrated at recurring points in time.

 
Time pattern of bundled goods receipt inspection

Not every cause of a process problem lies within the same process instance.

Isolating Capacity Overruns in a Targeted Way

In the current synthetic run, 92 goods receipt inspections can be identified for which the available inspection capacity was exceeded at the scheduled time. This corresponds to 1.62% of 5,670 inspections.

 
Goods receipt inspections with exceeded capacity

This turns the general time pattern into a concrete operational finding. The waiting time can be linked to a documented process condition: the shared capacity was not sufficient for these transactions.

This raises concrete questions for process improvement:

• Are the inspection intervals appropriately sized?
• Do certain material groups need to be prioritized?
• Does additional capacity make sense?
• Can inspection rules be differentiated?
• Which objects repeatedly cause the backlog?

Instead of "The inspection is slow." the analysis asks: "Which shared resource is holding back these specific transactions – and under which conditions does the backlog arise?"

Finding 4 · Payment: From Visible Correlation to Verified Effect

2,209 payments fall outside the cash discount period. In the end-to-end process, it is visible whether payments are made within or outside the cash discount period. In the current synthetic run, 2,209 payments fall outside and 2,717 within the cash discount period.

 
Payments within and outside the cash discount period

The resulting modeled lost cash discount is quantified down to the euro as a separate payment attribute. For the 2,209 payments outside the cash discount period, the demonstration dataset yields a perspective-wide modeled total of around €1.02 million.

 
Modeled lost cash discount

This gives rise to an economically relevant analysis question:

Which process conditions actually contribute to the cash discount period being missed?

Causality Also Means Sharpening Hypotheses

A plausible first hypothesis is that the backlog in goods receipt inspection delays later payments. Noreja therefore traces the inspections that actually exceeded capacity along their relationships all the way to payment.

 
Capacity-exceeding inspections traced to payment

The analysis separates two things that can easily be confused in a pure end-to-end view: an operational bottleneck can be real without automatically being the sole driver of a financial effect that becomes visible later.

The process manager therefore does not receive a premature "root cause", but a more precise basis for decision-making: the inspection backlog remains a relevant operational finding; for the lost cash discount, the invoice run, payment control, business clarifications and further conditions must also be considered.

Causal Process Mining tests root-cause hypotheses along the same affected business objects – instead of equating temporal proximity with causation.

Instead of "Where do we see waiting time and costs at the same time?" the analysis asks: "Which changeable condition actually explains the economic effect?"

Finding 5 · Supplier Performance: Same Standard Process, Different Lead Time

Three suppliers take roughly twice as long. Not every delay originates in your own process. The supplier analysis compares the same procurement logic along the connected supplier objects.

 
Supplier performance analysis

In the synthetic demonstration dataset, three supplier groups average around 14 to 15.5 days. The other suppliers mostly range between around 5.5 and 6.2 days.

The additional time is concentrated mainly on the transition Purchase order created → Goods receipt received.

At the same time, the analysis shows that the slow suppliers mostly follow the normal process path. An unusually high rework rate does not explain their longer duration either.

This shifts the question from "Why is our P2P process slow?" to:

"Why does the same standard process take significantly longer with certain suppliers?"

This distinction is crucial for the measure. An internal workflow redesign does not address an external delivery delay. Instead, delivery times, material planning, agreements and supplier management come into focus.

From Individual Findings to a Picture of Root Causes

The individual findings belong to the same end-to-end process but have different mechanisms of action. Minerva can bring together the results from the various perspectives and condense them for the process manager.

 
Minerva summarizes structural deviations in the P2P process

Among other things, the overall analysis distinguishes approval bypasses, invoice rework, sequence deviations, bundled processing and waiting times, as well as open or paused process objects.

The task is not to construct a single universal "root cause" for the entire P2P process. Rather, the different cause-and-effect mechanisms need to be separated.

 
Minerva condenses findings into a root-cause model

Minerva serves as an analysis and context assistant: the process manager can start with a business question instead of first having to combine view, filter and visualization themselves.

The business question comes first – not the operating logic of the analysis tool.

 
Condensed key statements from the Minerva analysis

From Finding to Prioritized Measure

A finding does not change a process on its own. After the analysis, the process owner must decide which insights will actually be acted upon.

This is where the bridge to the Business Impact Board can be built: findings are not merely collected, but evaluated, for example, by impact, implementation effort and uncertainty. Process Excellence and the business unit can thus jointly decide which improvement initiative is implemented first and which deliberately follows later.

Example Fields of Action

Prioritization is a business decision. Minerva can prepare analysis paths, context and options for action; responsibility for the measure remains with the process owner and the business unit.

The Cycle: Insight → Action → Impact → Feedback

The analysis does not end with the finding, nor with the implementation of a measure. What matters is whether the process behavior actually changes afterwards.

1. Insight: Identify error patterns, time patterns, missing prerequisites or conspicuous object groups.
2. Action: Understand the cause, formulate an improvement hypothesis, assess and prioritize impact and effort.
3. Impact: Implement the measure and define the expected business or economic effect.
4. Feedback: Measure the effect again using the same granular data and the same process logic.

Check After Every Measure

• Is maverick buying actually becoming less frequent?
• Is invoice rework decreasing for the clarification reasons addressed?
• Is the backlog at goods receipt inspection declining?
• Are delivery times becoming more stable for the affected suppliers?
• Is cash discount utilization actually improving?
• Has the problem shifted, or has it really been solved?

Five Principles for the Analysis

Preserve Granularity

Purchase requisition, approval, purchase order, item, goods receipt, inspection, invoice, payment and other business objects are preserved together with their relationships. The data is not reduced in advance to a single linear process view.

Reduce Complexity from a Business Perspective

For a specific business question, a suitable perspective on the Event Knowledge Graph is created. The representation becomes simpler without losing the underlying relationships.

Test Causal Hypotheses

Anomalies are not automatically interpreted as causes. The analysis follows the same affected business objects further and tests which conditions actually explain the observed effect.

Include Context

Relevant explanations often lie outside the operational transaction data. Tickets, comments, quality notifications or other business information can be linked to the affected business objects and included in the analysis.

Operationalize Insights

Findings become improvement hypotheses, are prioritized by impact, effort and uncertainty, and are measured again after implementation.

Frequently Asked Questions About Purchase-to-Pay

What is a Purchase-to-Pay process?

Purchase-to-Pay is the end-to-end process from the moment a procurement need arises to payment. In the special-purpose machinery scenario shown here, it covers purchase requisition, approvals, purchase order and order items, physical or digital fulfillment, goods receipt and inspection, as well as invoice, approval and payment.

Why is P2P particularly interesting for Causal Process Mining?

Because many business objects of different kinds and their dependencies interact. A purchase order can contain multiple items, physical and digital procurement follow different paths, inspection resources are used by multiple transactions at the same time, and invoices relate to purchase order, goods receipt and terms. Causes are therefore not always visible where their effect later occurs.

What is maverick buying?

Here, maverick buying refers to a purchase requisition that actually requires approval leading directly to a purchase order, bypassing the intended approval steps. In the synthetic demo run, this affects 1,145 cases, or 26.3% of the requisitions requiring approval.

Why is a short lead time not automatically positive?

Because speed is only one dimension of process quality. The maverick buying path is significantly faster than the regular approval path precisely because controls are missing. A fast process can therefore be worse from a business perspective than a slower but compliant one.

How does additional context help with invoice rework?

The Analyzer first shows that rework or manual clarification is taking place. Via Noreja Context, additional business information – for example from a ticket system – can be linked to the affected invoice ID. This reveals concrete reasons such as purchase order discrepancies, unclear invoice line items or issues with terms.

What does cross-case dependency mean in goods receipt inspection?

Multiple goods receipts share common inspection resources and can be processed in the same batch runs. An individual transaction may therefore wait even though no error is visible in its own history. The cause lies in a shared resource and thus outside the isolated view of that one transaction.

Does the inspection backlog automatically cause the lost cash discount?

No. Goods receipt inspection can be a real operational bottleneck. For the economic effect, however, it must be tested separately whether the same affected business objects actually miss the cash discount period disproportionately often later on. Causal Process Mining therefore separates visible correlations from verified cause-and-effect hypotheses.

What role does Minerva play?

Minerva supports the process manager in investigating business questions across process knowledge, analysis results and additional context. It can bring findings together, form comparison groups, structure root-cause hypotheses and prepare analysis paths. The business decision on measures remains with humans.

How are findings prioritized?

Process owners can evaluate findings, for example, by impact, implementation effort and uncertainty. This turns an analytical anomaly into a prioritized improvement initiative. After implementation, the effect is measured again against the granular process data.

Do the figures come from a real special-purpose machinery manufacturer?

No. All figures come from a synthetic demonstration dataset. They serve to make analysis paths, causal questions and the connection between process data and business context easy to follow.