Approval Laundering: The Invoice Fraud Hiding in Plain Sight

Imagine your company has a €5,000 approval threshold. Any invoice above €5,000 from a supplier requires a second signature — a manager review, a CFO approval, or a board-level sign-off depending on the amount. Invoices below €5,000 are processed automatically or routed to a lower-level approver who handles high volume and does not have time to inspect every line.

Now imagine a supplier — or an employee colluding with a supplier — who knows this. They send three invoices on the same day:

Invoice #FC-2026-0010  €1,900  "Marketing services (batch 1/3)"
Invoice #FC-2026-0011  €1,900  "Marketing services (batch 2/3)"
Invoice #FC-2026-0012  €1,900  "Marketing services (batch 3/3)"
────────────────────────────────────────
Total in 24h:           €5,700  Same supplier, same date

Each invoice is €1,900 — well below the €5,000 threshold. Each one looks like a legitimate marketing service. Each one is processed without a second look. But the total is €5,700, which should have triggered a manager review.

Nobody saw it because nobody was looking at the sum. The ERP processed three separate invoices. The approval workflow checked three separate thresholds. The accounts payable clerk entered three separate line items. The forest was never visible — only the trees.

The root cause is simple: approval systems are designed to evaluate one invoice at a time. The logic is:

if invoice.total > threshold:
    route_to_manager()
else:
    auto_approve()

There is no state that says "how much have we already received from this supplier today?" The threshold check is stateless — it does not know about the other invoices that arrived in the same window. And even if your ERP has a "duplicate invoice check," it is looking for the same invoice number or the same document hash — not for different invoices from the same supplier that add up to more than the threshold.

This is not a bug in any particular ERP. It is a structural gap in how approval workflows are designed. The unit of evaluation is the invoice, not the supplier-day. And until you change the unit of evaluation, no amount of OCR, AI, or process automation will close the gap.

The fix is a single deterministic signal. At invoice ingestion time — before the invoice enters the approval workflow — compute:

window_24h_total = sum(
  invoice.total
  for invoice in seen_invoices
  if invoice.supplier_tax_id == this_invoice.supplier_tax_id
  and invoice.issue_date within 24h of this_invoice.issue_date
)

if window_24h_total > split_threshold:
    flag_for_human_review("Splitting window exceeded")

This signal is:

• Deterministic — same inputs, same output, every time. No machine learning model, no confidence score, no false positives from model drift.
• Computable at ingestion — before the invoice is paid, before it enters the approval workflow, before any human touches it.
• Grouped by tax ID, not by supplier name — supplier names can vary ("Suministros Iberica SL" vs "Suministros Iberica S.L."), but tax IDs are unique and normalized.
• Configurable — the threshold and the window size are per-tenant settings, not hardcoded. A company with a €2,000 threshold can set a different trigger point than one with €10,000.

In Pliuz, this signal is one of four deterministic checks computed when an invoice enters the system. The others are:

When the splitting window signal fires, the invoice is routed to a human approver via Slack — with the context of why it was flagged: the individual invoice amount, the 24-hour cumulative total, and the threshold that was crossed. The approver sees the forest, not just the tree.

Crucially, the signal is computed by a deterministic rules engine — not an LLM. There is no model that could hallucinate a false positive or miss a real one. The rule is transparent, auditable, and produces the same result every time.

The ACFE Report to the Nations estimates that billing schemes — which include invoice splitting — account for roughly 15% of occupational fraud cases, with a median loss of $100,000 and an average duration of 12 months before detection. The schemes are most common in small and mid-sized organizations, where separation of duties is weaker and a single approver may handle both invoice entry and payment authorization.

But the direct loss is only part of the cost. The indirect costs include:

• Audit findings — when an external auditor finds splitting patterns that the company's own controls did not detect, it weakens the audit opinion and can trigger material weakness findings.
• Regulatory exposure — under SOX §404 and the EU AI Act (Article 12, record-keeping), companies must demonstrate that their controls are effective. A structural blind spot in the approval workflow is a control deficiency.
• Trust erosion — when the CFO learns that €5,700 was paid in three chunks without anyone noticing, the question becomes: "What else did we miss?"

Approval laundering is not a sophisticated fraud. It does not require deep technical knowledge, forged documents, or compromised systems. It exploits a simple structural gap: approval systems evaluate invoices one at a time, not as a cumulative sum per supplier.

The fix is equally simple: compute a rolling 24-hour sum per supplier, and flag it when it crosses a threshold. It is one deterministic rule — no machine learning, no model drift, no false positives from hallucination. Just math.

If your approval workflow does not have this signal today, the question is not whether it is happening — it is how much it is costing you.