In short: 15-25% of transactions need special handling, but most of them aren't errors. They are known alternative scenarios (sole-source or emergency procurement, deviations within tolerance). The word "exception" covers three different things: process-level alternatives, operational data discrepancies, and genuinely unwanted maverick buying. That last one is usually a UX problem more than a discipline problem. The answer is rule-based routing: the system uses rules to decide which transaction takes which path, and sends only the truly unique cases to a human decision, automatically and auditably. This can raise coverage from 80% to 95-98% without losing control.
A typical situation: a critical component in the server farm fails and needs immediate replacement, or the business loss will be significant. The normal procurement process takes 5 to 7 days, and the approval chain has three levels. The framework-contract supplier can only deliver in two days. There is an alternative supplier who could deliver within 4 hours, but they aren't on the approved vendor list. This situation isn't a system failure. It's part of everyday operations.
One of the most dangerous illusions in corporate process management is that 80% of transactions are "standard" and only 20% are "exceptions". The ratio is misleading, because that 20% often hides the decisions with the greatest strategic and financial impact.
Depending on organisation size, 500 to 2,000 procurement transactions run through a company every month. Industry experience suggests that 15-25% of them need some form of special handling. If each case takes 1 to 3 hours of manual coordination on average (email exchanges, phone calls, meetings), depending on complexity, that adds up to hundreds of lost working hours a month.
Beyond the direct time cost, there is also a problem of mindset. The traditional view treats these "exceptions" as process-level failures: something doesn't fit the rigid process, so the system sets it aside and it needs human intervention. In reality, these are known alternative scenarios that an intelligent system should handle natively.
In corporate procurement, the word "exception" covers three completely different phenomena, and that is where most of the confusion comes from.
These are business-justified, predefined alternative paths. For example:
The point: these are legitimate alternative paths that software should support just as well as the "standard" process.
These are the discrepancies that come up in day-to-day operations and stem from data reconciliation issues.
Three-way match discrepancies: the purchase order (PO), the goods receipt note (GRN), and the invoice don't match perfectly. For example, we order 300 boxes of rubber gloves, but only 299 arrive. Or: for special sterile filter cartridges, the contracted price was EUR 85 per unit, but the invoice says EUR 86. For 50 units, that's a EUR 50 difference.
Investigating these small discrepancies often costs more than the discrepancy itself. If a controlling specialist spends an hour finding out the cause of a EUR 5 difference, the process costs many times the discrepancy.
That's why the intelligent approach is to define tolerance thresholds. For example:
If the deviation is below the defined limits, the system approves the invoice automatically. If it's above them, it needs a human decision.
Transactions without a PO: some cost types would carry a disproportionate administrative burden in a PO-based process: utility bills, taxes, membership fees, rent. These should be handled as predefined exceptions.
The point: these are operational administrative disruptions, not business decisions. But they are exactly what takes the most time from finance and procurement teams when there is no proper automation and no well-set tolerance threshold.
This is the only category that is genuinely an unwanted exception: when someone bypasses the official procurement process. For example, buying office supplies from a random webshop with a company card, when they could use the approved catalogue.
Why does it happen? Usually not out of bad intent. The official process is too slow or complicated, the approved suppliers' range doesn't meet the need, or users used to B2C experiences are frustrated by how the corporate system works.
The consequences: lost volume discounts because framework contracts go underused, opaque costs, more administration after the fact, and compliance risk from unaudited suppliers.
The point: maverick buying is often a user experience (UX) problem more than a discipline problem. The best remedy is a system where the official route is faster and more convenient than going around it.
The way these problems are handled differs fundamentally between traditional ERP systems and modern, workflow-based procurement platforms.
These systems were designed for recording transactions, not for managing processes. They consisted of separate modules (finance, procurement, warehouse), and their logic was rigid.
These systems handle the whole process as a single integrated workflow, from the purchase request to invoice payment. Exception handling is a built-in, configurable part of the process.
Understanding the fundamental differences in approach
| Aspect | Legacy ERP Systems | Modern Workflow Platforms |
|---|---|---|
| Philosophy | Data recording, transaction storage | Process automation |
| Exception Logic | Rigid, hard-coded | Dynamic, rule-based |
| Approval | Linear, static, solution often outside system | Multi-level, conditional, intelligent routing, within system |
| Flexibility | Low, every change requires development | High, configurable without coding |
| Visibility | Fragmented, hard to track | Real-time, complete audit trail |
| Escalation | Manual (phone, email) | Automatic, SLA-based |
Data recording, transaction storage
Process automation
Rigid, hard-coded
Dynamic, rule-based
Linear, static, solution often outside system
Multi-level, conditional, intelligent routing, within system
Low, every change requires development
High, configurable without coding
Fragmented, hard to track
Real-time, complete audit trail
Manual (phone, email)
Automatic, SLA-based
Fluenta One doesn't start from the idea that "there is a standard process and there are exceptions". Instead, the system uses rules to decide which transaction takes which path.
This means:
The flexibility lies in the fact that you can define as many paths as you like, and the rules can be combined and changed at any time.
In the old system:
In Fluenta One, for example, the following process can be set up:
The result: what used to take 1 to 2 days of manual coordination now takes 2 to 4 hours, fully transparent and auditable.
Let's take a concrete calculation for a large enterprise, where exceptions tend to be complex.
Starting data:
Savings:
Important: this calculation works at the top of the range. With simpler exceptions (1 to 2 hours of manual handling) or fewer transactions, the saving is proportionally lower, but the order of magnitude remains significant. Every organisation should recalculate with its own transaction volume and hourly rates.
Beyond the direct cost:
Faster decision-making. Business opportunities aren't lost to slow reactions, and the number of emergency purchases falls, and with it their higher prices.
Better supplier relationships. Faster payments lead to better terms, and fewer disputed invoices lead to more stable cooperation.
Higher compliance. A complete audit trail makes internal and external audits simpler, and automatic compliance checks build compliance into the process.
Strategic data asset. Exceptions stored in a structured way can be analysed: which suppliers make frequent mistakes? Which departments generate the most urgent requests? Manual processes produce fragmented data, while automation becomes a tool for proactive process improvement.
Quantifying the benefits of process automation
| Metric | Manual Process | Automated Process | Improvement |
|---|---|---|---|
| Average processing time/exception | Days or weeks | Hours or minutes | >70% |
| Cost/invoice | ~$13 | ~$2.81 | ~80% |
| Error rate | High (typos, duplicates) | Minimal | >90% |
| Transparency | Low, fragmented | Complete, real-time | 100% |
| Auditability | Retroactive reconstruction | Immediate, complete log | Significant |
Days or weeks
Hours or minutes
>70%
~$13
~$2.81
~80%
High (typos, duplicates)
Minimal
>90%
Low, fragmented
Complete, real-time
100%
Retroactive reconstruction
Immediate, complete log
Significant
The invoice processing cost figures come from industry benchmarks: Ardent Partners' State of ePayables research puts the average cost of processing an invoice at around USD 13, while Levvel Research and APQC benchmarks show it falling to around USD 2.81 for fully automated processes.
A further layer of complexity is operating across multiple countries. When a company works with international suppliers, each country's regulatory environment generates additional "exceptions":
Within an organisation, different departments have different procurement needs. Marketing needs fast response times, creative agency services, and media space; IT needs complex technical specifications and compatibility requirements; production needs high-volume, repetitive purchasing.
The goal is for everyone to work on one shared platform, along processes tailored to their own needs, in a controlled and transparent way.
Exceptions are constantly present in business operations, so a system that handles only standard cases reaches 80% coverage at most. By integrating "exceptions" natively, as predefined alternative paths in place of after-the-fact firefighting, Fluenta One delivers 95-98% coverage.
The essence of digital transformation is that the machine handles routine work efficiently, even when it's complex, so that people can focus on strategy and innovation.
That is exactly what Fluenta One makes possible: a system that is standardised and flexible, automated and controlled at the same time, and in which the exception is simply another well-handled case.
What counts as an "exception" in procurement?
Three different things: process-level alternatives (e.g. sole-source or emergency procurement), operational data discrepancies (e.g. three-way match discrepancies), and policy exceptions, i.e. maverick buying. The first two aren't errors; they are known cases that need to be handled.
What percentage of transactions need special handling?
Industry experience puts it at 15-25%, and these often contain the decisions with the greatest strategic and financial impact, so they shouldn't be treated as a by-product.
What is a tolerance threshold, and why is it useful?
A predefined limit (e.g. ±2% or a maximum EUR 50 price deviation) within which the system approves automatically, because investigating a small discrepancy often costs more than the discrepancy itself.
What is maverick buying, and how can it be prevented?
It's when someone bypasses the official procurement process. It's usually a UX problem more than a lack of discipline: the best remedy is a system where the official route is faster and more convenient than going around it.
How does exception handling in a workflow platform differ from a legacy ERP?
An ERP works with rigid, hard-coded rules, and the resolution often happens outside the system (email, phone, Excel). A workflow platform handles exceptions inside the process, with configurable, rule-based routing, automatic escalation, and a complete audit trail.
How much can realistically be saved?
It depends heavily on transaction volume, the complexity of exceptions, and pay levels. The example in the article applies to a large enterprise with complex exceptions; in simpler cases the saving is proportionally lower. It's worth recalculating with your own data.
.png)
.png)
.png)
.png)