A request that would have been unusual in 2009 had become routine by 2013: "Can you tell me why days sales outstanding went up last quarter?" Not the number — the number was on the dashboard. The reason. That question sits outside what a transaction processing function was built to answer. Processing is about accuracy and throughput: code the invoice correctly, post it on time, reconcile the account. Explaining a movement in a metric requires segmenting data, comparing periods, isolating variables and forming a defensible conclusion. Different skill, different tooling, different kind of person. The interesting thing about 2013 is not that the demand appeared. It is that most organizations asked for it without changing anything about how the back office was staffed, measured or compensated — and then were surprised when the answers were thin.
Why the Demand Appeared When It Did
Three things converged. Transaction processing had been substantially industrialised. Shared service centres, offshore delivery and workflow automation had taken the cost of a processed invoice down far enough that further reductions were marginal. The obvious next question from a CFO was what else this function could produce. The data had accumulated. A back office that had been processing electronically for a decade was sitting on years of granular transaction history — every invoice, every payment, every supplier interaction, every exception. That is a genuinely valuable dataset, and it was almost entirely unused beyond the reports it was designed to produce. And the tooling had become accessible. Self-service business intelligence, pivot-heavy analysis and visualisation tools meant that producing an analysis no longer required a data warehouse project and a BI team. Someone competent with data could answer a question in an afternoon.
The Analysis That Only the Back Office Can Do
It is worth being concrete about what this function can produce that nobody else can, because the generic "insights" framing obscures it. Why customers pay late, by customer and by cause. Not the DSO number, but the decomposition: disputed invoices, incorrect purchase order references, invoices sent to the wrong contact, customers who simply pay on their own cycle regardless of terms. Each cause has a different fix and only the AR team's exception data distinguishes them. Where processing exceptions actually originate. Most exception analysis stops at the exception. The useful version traces upstream: a supplier whose invoices fail matching every time because the purchase order is raised after delivery, a business unit whose coding is wrong sixty percent of the time, a contract whose terms do not match what the system expects. Supplier behaviour and spend concentration. Who is being paid, on what terms, how often outside contract, with what price variance across entities. Procurement usually has the contracts; only accounts payable has what actually happened. The real cost of a process, per unit and per variant. Cost per invoice is a blunt average. Cost per invoice by channel, by supplier type and by exception path shows where the money goes and which fifteen suppliers cause a third of the manual work. Working capital levers with numbers attached. Which payment terms are actually being honoured, what early payment discounts are being missed, where cash is trapped in disputes. This is the analysis that CFOs value most and that is least often produced.
Why Most Attempts Failed
The skill was assumed rather than hired. "Analytics" was added to job descriptions without changing the recruitment profile, the pay band or the training. A team selected and trained for accurate, high-volume processing does not automatically contain people who can frame a question, structure an analysis and defend a conclusion. Those are genuinely different aptitudes and both are valuable. The time did not exist. Analysts were expected to produce insight alongside a full processing workload measured in items per day. Analysis is the work that loses to a queue every time, because the queue has a deadline and the analysis does not. The metrics did not change. Teams continued to be measured on throughput, accuracy and cycle time. Nothing in the performance framework rewarded an analysis that saved the business money, so nothing in the behaviour changed. The data was not fit for it. Analysing supplier spend requires a clean supplier master. Analysing payment behaviour requires consistent customer records. Years of duplicate records, inconsistent coding and free-text fields meant the first six weeks of any analysis was data cleanup, which nobody had budgeted. And the outsourcing contract did not permit it. Where processing had been outsourced, the contract specified transactions, service levels and price per unit. It contained no provision for analysis, no mechanism to request it, and no commercial incentive for the provider to identify improvements that would reduce the volume they were paid for. That last point deserves emphasis because it is structural. A per-transaction contract pays the provider more for processing more transactions. Asking that provider to find ways to reduce transaction volume is asking them to reduce their own revenue. Outcome-based commercial models exist to resolve exactly this, and most organizations never made the change.
| Question | Data to examine |
|---|---|
| Why do customers pay late? | Payment records, disputes, references, contacts and terms. |
| Where do exceptions originate? | Transaction exceptions and their supplier or process context. |
| How does spend differ from the agreement? | Posted purchases, supplier master and contracted terms. |
| What does each process variant consume? | Channel, exception path and attributable work effort. |
| Where is working capital held up? | Terms, discounts and unresolved disputes. |
Qualitative summary of this article's source text, not a measured outcome or performance estimate.
What Worked Instead
Separate the roles explicitly. A small number of dedicated analyst positions, recruited differently, paid differently, with protected time and no processing queue. Two people with real capacity produce more than thirty people with an aspiration. Start from a question the CFO already has. Not a dashboard project. One specific, current, uncomfortable question — why margin fell in a region, why AP costs rose, why a customer segment pays late — answered properly. Credibility from one good answer funds everything after it. Fix the master data as a prerequisite. Supplier and customer master cleanup is unglamorous and is the gating factor on every subsequent analysis. It also improves processing quality, so it pays for itself twice. Renegotiate the commercial model before asking a provider for insight. Gain-share, outcome-linked fees or a separately scoped analytics workstream. Without one of these, the request is misaligned with the provider's economics and will not be met seriously. Build the career path. If the only progression from processing is into supervision, analytical talent leaves. An analyst track with real progression is what makes the capability stick rather than being rebuilt every two years.
Practical Guidance for Adding Analytics Capability
- Hire for the skill; do not assume it. Framing questions, structuring analysis and defending conclusions are different aptitudes from accurate high-volume processing. Both are valuable and they rarely coexist in the same role.
- Protect analyst time from the queue. Analysis loses to processing every single day unless the analyst has no processing responsibility at all.
- Change what you measure. Throughput and accuracy metrics produce throughput and accuracy. If you want insight, something in the performance framework has to reward it.
- Clean the supplier and customer master first. Every analysis depends on it and the cleanup improves processing quality as a side effect.
- Answer one important question properly before building a dashboard. Dashboards without a demonstrated analytical capability behind them become wallpaper within a quarter.
- Trace exceptions to their upstream cause. The value is not in counting exceptions but in identifying the supplier, business unit or contract term that generates them.
- Align the outsourcing commercial model with the ask. Per-transaction pricing rewards volume. Insight that reduces volume requires a different contract.
- Publish the findings where decisions are made. Analysis that stays inside finance changes nothing. It has to reach the people who own the upstream processes.
The Regional Context
In the Gulf this shift has a particular shape, driven by structure and by regulation. Multi-entity groups here generate an unusual volume of cross-entity analytical questions: why the same supplier is paid on different terms in Dubai and Riyadh, why processing cost per invoice differs by a factor of three across entities, where intercompany balances are accumulating. Those questions are only answerable from consolidated back-office data, and they are frequently the most valuable analysis available to a regional CFO — partly because nobody has ever looked. Regulatory change has also created analytical demand directly. VAT and corporate tax introduced reporting obligations that require analysing transaction data rather than merely posting it. ZATCA e-invoicing in Saudi Arabia produces a structured, government-validated record of every invoice, which is both a compliance requirement and a far better analytical dataset than most organizations previously had. Compliance built the data foundation that analytics needed. The constraint is talent. The regional market for people who combine finance process knowledge with genuine analytical capability is thin, competitive and expensive. Organizations that succeeded generally built internally — identifying processing staff with analytical aptitude and investing in them — rather than competing for a scarce external pool. That is slower and it produces people who understand the underlying processes, which turns out to matter more than tool proficiency. Workforce mobility adds urgency. Where team tenure is shorter than in other markets, analytical capability held in individuals rather than in documented methods and maintained datasets disappears with them. Codifying the analysis — the queries, the definitions, the data preparation — is not documentation overhead here; it is the only way the capability survives.
What Changed Again
The skill profile has shifted twice since 2013. The first shift was automation. When RPA and then intelligent document processing absorbed much of the routine matching and coding, the remaining human work became exception handling and judgement — which is analytically adjacent by nature. The distinction between processor and analyst narrowed from the processing side. The second is happening now. AI tools can query transactional data conversationally, produce a segmented analysis in seconds and write the summary. The mechanical parts of analysis — pulling the data, structuring the comparison, building the chart — are becoming inexpensive. What is not becoming inexpensive is knowing which question to ask, recognising when an answer is wrong, and understanding the business process well enough to interpret what the numbers mean. A model will confidently explain a DSO movement using data that excludes a business unit, or attribute a cost increase to a driver that is actually a coding change. Catching that requires someone who knows how the invoices actually get processed. Which means the 2013 conclusion holds, with a different emphasis. The back office does need analytical capability. It needs it less for producing analysis and more for validating it — and that requires exactly the process knowledge these teams already have, combined with enough analytical literacy to know when something does not add up.
Common Questions
Why did back office teams start needing analytical skills?
Transaction processing had been industrialised to the point where further cost reduction was marginal, a decade of granular transaction data had accumulated unused, and self-service analysis tools made it possible to answer questions without a data warehouse project.
What analysis can only the back office produce?
Decomposition of why customers pay late by cause, the upstream origin of processing exceptions, actual supplier behaviour versus contracted terms, true cost per process variant, and working capital levers with real numbers attached. All of it depends on exception and transaction detail that only this function holds.
Why do most attempts to add analytics fail?
The skill is assumed rather than hired, analyst time is not protected from the processing queue, performance metrics still reward throughput only, master data is too poor to analyse, and outsourcing contracts priced per transaction give providers no incentive to reduce volume.
Does AI remove the need for analytical skills in the back office?
It removes much of the mechanical work — pulling data, structuring comparisons, drafting summaries. It does not remove the need to know which question to ask and to recognise a wrong answer, which requires the process knowledge these teams already have.
Add Analytics Capabilities to Your Back Office — Outpace builds the data foundation, the roles and the commercial model that turn transaction volume into answers.