---
title: "Tutorial P2P - Loss of Discount - Working Capital"
url: "https://docs.noreja.com/en/article/p2p-tutorial-loss-of-discount-working-capital"
language: "en"
last_updated: "2026-09-22T10:50:43.802Z"
---

# Tutorial P2P - Loss of Discount - Working Capital

> **TL;DR**   
> **Goal:** Deliberately delay payments and thereby generate cases in which an existing cash-discount deadline is exceeded.   
> **Prerequisites:** Invoice, invoice approval and payment are part of the `Causal Chain`.   
> **Result:** Certain invoices are deliberately processed later, so that their payment can fall after `skonto_frist_am`.

## The business question

Companies sometimes try to execute payments as late as possible in order to keep liquidity within the company for longer.

From a working-capital perspective, this can initially seem sensible.

At the same time, however, a conflict of objectives arises:

**What happens when a deliberately delayed payment causes an existing cash-discount deadline to be missed?**

For our synthetic use case, we therefore generate a relationship between:

`pruefer_team`

→ longer processing time

→ later payment

→ possible exceeding of the cash-discount deadline.

## Desired data picture

The invoice already contains a fixed:

`skonto_frist_am`

In our model, this lies **14 days after the invoice was recorded**.

A normal case can look like this, for example:

`Rechnung`

→ `Rechnungsfreigabe`

→ `Zahlung`

→ payment takes place before `skonto_frist_am`

With deliberately delayed processing, by contrast, the following should arise:

`Rechnung`

→ additional waiting time

→ `Rechnungsfreigabe`

→ `Zahlung`

→ payment lies after `skonto_frist_am`

## 1\. Using a Conditional Rule

For this use case we do not need a new `Special Behaviour`.

Instead, we again change the process time.

Open: `04 Special Behaviour`

and go to: `Conditional rules (A / C / D)`

Choose:

**Effect:**   
`A · Timing (change gap)`

This lets us extend an existing time gap depending on a business attribute.

## 2\. Selecting the invoice as the starting point

As the:

**Activity (gap after)**

we choose: `rechnung`

The additional waiting time is thereby built into the process after the invoice.

At this point, the existing P2P process already has a normal processing time. For the affected cases, we now deliberately increase it.

## 3\. Setting the condition on the checker team

Choose:

**Condition – source:**   
`Column of this activity`

**Column:**   
`pruefer_team`

**Operator:**   
`=`

**Value:**   
`Kreditorenbuchhaltung`

This links the delay to a concrete business attribute.

The statement reads:

> If the invoice is processed by the team `Kreditorenbuchhaltung`, the subsequent process time should be extended.

![](https://cdn-assets.productfruits.com/c89f6479-df00-4f20-9a03-83541dd2562c)

## 4\. Generating twelve days of additional waiting time

Under:

`Effect on gap after the activity`

choose:

`+ days`

and enter:

`12`

This adds **12 additional days** to the affected cases.

The basic principle corresponds to the existing P2P demo rule for working capital: there, too, twelve additional days are generated for invoices from the `Kreditorenbuchhaltung` team.

Set as the:

**Tag:**

`ZAHLUNG_BEWUSST_VERZOEGERT_WORKING_CAPITAL`

![](https://cdn-assets.productfruits.com/9ec4e04b-1708-42e4-8d7f-676f05a5f2ff)

## Why exactly twelve days?

In our data model, the invoice has:

`skonto_frist_am`

with a fixed distance of **14 days** from the invoice recording.

At the same time, the normal process between invoice and payment already needs several days.

If we additionally build in:

`+12 Tage`

many of these cases will exceed the cash-discount deadline.

This produces a deliberately generated conflict of objectives:

**keeping liquidity for longer**

against

**losing a possible cash-discount advantage**.

## A fixed deadline instead of a deadline shifted along

The important point here is:

`skonto_frist_am`

is a **deadline**.

The deadline should not automatically shift back just because the internal process takes longer.

Otherwise the additional delay would not produce any economic effect.

The desired pattern is therefore:

`skonto_frist_am` remains unchanged

while:

`zahlung_ausgefuehrt_am`

moves back.

This later allows checking:

`zahlung_ausgefuehrt_am > skonto_frist_am`

## What do we model in the Simple training?

In the Simple model, we first generate the **causal time conflict**:

`Kreditorenbuchhaltung`

→ additional 12 days

→ later payment

→ cash-discount deadline possibly exceeded.

For this, the tables already contain the relevant fields:

`rechnung.skonto_frist_am`

`rechnung.skonto_prozent`

`zahlung.zahlung_ausgefuehrt_am`

`zahlung.skonto_genutzt`

`zahlung.skonto_verlust_eur`

Important, however:

The normal data run does **not automatically recalculate** `skonto_genutzt` and `skonto_verlust_eur` after such a timing rule.

In the Simple training we therefore first look at:

**Did the payment take place before or after the cash-discount deadline?**

The actual financial recalculation follows later in **Expert Mode**.

## What is added in Expert Mode?

In the Expert part, we connect this principle with a real:

`Capacity Bottleneck`

and:

`Backlog`

There, the delay no longer arises merely from a fixed defined rule, but from limited process capacity.

The additional delay is then propagated downstream through to the payment.

After that, the Smart Data Forge can actually redetermine:

`skonto_genutzt`

and:

`skonto_verlust_eur`

when the shifted payment lies past the fixed deadline.

This later extends the causal chain to:

`Kapazitätsengpass`

→ `Backlog`

→ longer cycle time

→ delayed payment

→ lost cash discount.

In the Simple model we already lay the business groundwork for this.

## The finished rule

| Setting | Value |
| --- | --- |
| Effect | `A · Timing (change gap)` |
| Activity | `rechnung` |
| Condition source | `Column of this activity` |
| Column | `pruefer_team` |
| Operator | `=` |
| Value | `Kreditorenbuchhaltung` |
| Gap effect | `+ days` |
| Value | `12` |
| Tag | `ZAHLUNG_BEWUSST_VERZOEGERT_WORKING_CAPITAL` |

![](https://cdn-assets.productfruits.com/544821d1-8617-4da9-a1a0-85a9077ad078)

## What should I later see in Noreja?

Cases with:

`pruefer_team = Kreditorenbuchhaltung`

should exhibit a significantly longer cycle time between invoice and payment.

In addition, we can check:

**Which payments lie after** `**skonto_frist_am**`**?**

**Which teams or process characteristics explain delayed payments?**

**How strongly do cases with and without a working-capital delay differ?**

Later, the financial question can also be derived from this:

**How much cash discount is lost through process delays?**

With this, we connect a process cause with a possible financial effect for the first time.

## Difference from poor supplier performance

Both use cases use a `Conditional Rule`, but pursue different business hypotheses.

**Poor supplier performance**

`Lieferant`

→ process takes longer.

**Working Capital**

`internal checker team`

→ payment is deliberately delayed

→ financial deadline can be exceeded.

This makes it visible that longer cycle times can arise from both **external** and **internal** causes.

## Common mistakes / things to watch out for

**Use** `**+ days**` **and not** `**× factor**`**.**   
We want to add twelve days deliberately.

**Do not shift** `**skonto_frist_am**` **along.**   
The deadline must stay fixed so that a delayed payment actually becomes recognizable.

**Distinguish Simple and Expert.**   
In the Simple model we generate the delay and the cash-discount risk. The automatic calculation of the actual cash-discount loss follows later in the Expert part.

## Result

With this, our Simple data set now contains all the intended synthetic use cases:

**Maverick Buying**   
→ an intended approval path is bypassed.

**Poor supplier performance**   
→ a supplier extends process times.

**Order change / rework**   
→ an order is processed after the fact.

**Wrong Order**   
→ order and approval lie in the wrong temporal sequence.

**Open processes**   
→ cases deliberately end at various points in the process.

**Working Capital / cash-discount risk**   
→ internal decisions delay the payment and can jeopardize financial deadlines.

With this, the **Simple part of the demo training is complete**.

## Next step

Save this state as:

`Config 2 – Simple`

In the next section we switch to:

`Mode: Expert`

and extend the P2P model with different procurement paths, capacity bottlenecks, backlogs, delay propagation and the actual calculation of cash-discount losses.

**Next:** [**Tutorial P2P Expert XOR -  different procurement paths**](https://docs.noreja.com/en/article/p2p-expert-xor-tutorial-different-sourcing-methods)