Very few discussions about enterprise AI explain concretely how an AI agent should make decisions about back-office processes: matching invoices, closing the books, or reconciling supplier documents scattered across four different software tools. Fewer still are the off-the-shelf AI platforms able to use different reasoning approaches depending on the situation.
Yet this is decisive, because every back-office problem requires a fundamentally different reasoning strategy. An agent that monitors your ERP or payroll for anomalies should not reason like an agent that matches an invoice against a purchase order, a goods receipt and a contract. Getting this wrong is exactly why so many enterprise AI deployments disappoint.
Most vendors apply a single reasoning approach to every problem, ship a generic copilot, and are then surprised that 95% of enterprise AI pilot projects deliver no measurable return (MIT, 2025). Microsoft 365 Copilot is already built into 450 million commercial seats… and yet only 3.3% of users pay to use it. The tool is right there, at hand, and people still do not use it. The problem was never access. It was value.
At CERVOX, we design agentic AI for the back office of French SMEs: your ERP, your accounting, your payroll, your CRM, your email and every other tool in your ecosystem. Here are the four reasoning strategies we use in production, and how each one maps to the real work of our cognitive neurons.
The differences are not theoretical: they determine whether your agent handles exceptions calmly, or collapses as soon as real data departs from the demo script.
ReAct: think, act, observe, adapt
Where we use it: month-end close automation
Month-end close is not a single task. It is a chain of interdependent steps where the outcome of one decision shapes the next. The cognitive neuron spots unposted journal entries in your software, reasons about the cause of the block (missing approval? failed data exchange? format error?), takes corrective action (it re-runs the flow, alerts the approver, reformats the data), then observes whether the problem is solved before moving to the next item.
ReAct is the right choice here, because the agent cannot pre-plan a close sequence. It does not know what it will find until it has looked. A broken integration between your ERP and a downstream system may call for a data fix, a retry, or escalation to a human colleague, and the agent only knows which path to take after inspecting the error. Each observation feeds the next reasoning step.
In practice, our close neurons handle dozens of exception categories this way: accrual variances, missing exchange rates, payment failures, period locks. The ReAct loop lets the agent handle each exception on its own logic, rather than following a rigid script that breaks at the first surprise.
Simple feedback: generate, evaluate, retry
Where we use it: journal entry automation
When an agent creates a journal entry, the validation criteria are explicit and deterministic. Does the account combination exist in the chart of accounts? Do the values comply with the chart's control rules? Do debits equal credits? Is the period open? Is the amount within approval thresholds?
Simple feedback handles this cleanly. The agent drafts the entry, the evaluator checks it against the validation rules, and if something fails (for example an invalid intercompany segment or an imbalance) the agent receives precise feedback on the error and regenerates the corrected entry. No philosophical reasoning required. Just: “This segment does not exist. Fix it and resubmit.”
This direct loop is what makes journal entry automation reliable at scale. The agent does not overthink: it generates, validates and corrects in tight cycles. And because every validation step and every correction is logged, the whole generate-evaluate-correct chain becomes part of the audit trail. When an auditor asks “why did the system create this entry?”, the feedback log answers the question without anyone having to reconstruct the logic after the fact.
We also apply simple feedback to our monitoring function. When the agent detects an anomaly in your management processes (a spike in invoice imports, a gap in depreciation calculations, a pattern that deviates from historical norms) it generates an alert assessment, checks it against configured thresholds and known events (period close, system migration, seasonality), and only raises the alert if the assessment meets the criteria. If the first assessment does not clear the bar, the agent adjusts and re-evaluates. This is what eliminates the flood of false positives that makes most monitoring tools unusable within a month.
Reflexion: self-assess, learn, improve
Where we use it: supplier invoice matching (4-way match)
Matching an invoice to a purchase order looks simple… until you do it across purchasing, receiving and accounting, in systems that share no common data model. A 4-way match validates the invoice against the purchase order, the goods receipt, the contract terms and, where relevant, an inspection or acceptance step, all across several software tools.
The hard part is not the match. It is the variance. An invoice comes in at €47,200 against a €44,000 purchase order. A legitimate extra line? A price revision clause? Double billing? Currency rounding across 340 items?
Reflexion is essential here, because the agent must learn from each matching cycle. When it first flags an invoice as a duplicate, but a colleague overrides that decision because the extra line was covered by a contract amendment, the agent does not just accept the correction: it reflects on why its reasoning was wrong. Was it missing the amendment context? Was it weighting the amount variance too heavily compared with line-by-line analysis? These reflective lessons are stored and applied to the next similar case.
Over time, the agent builds a real understanding of each supplier's habits. It learns that Supplier A always bills express delivery on a separate line that exceeds the original purchase order amount. It learns that currency rounding variances below €500 on large volumes are almost always immaterial. It learns which variances are real problems and which are normal business. This is fundamentally different from a rules engine that would flag any breach of a 5% tolerance and dump it into an exceptions queue with no context at all.
In company workflows, reflexion refines classification and routing, not the underlying accounting logic. Corrections improve how exceptions are interpreted, without changing the underlying rules.
ReWOO: plan everything, then execute
Where we use it: external reconciliation
External reconciliation is one of the hardest problems in corporate finance, because the agent compares documents from outside the company with your internal records, and those external documents arrive in every format, language, naming convention and template imaginable.
We designed a reconciliation agent for a company that receives more than 4,000 documents a year from more than 250 external counterparties in more than 30 countries. Each counterparty sends its own version of the same standard document types, but in its own templates and formats. One country sends impeccable Excel files. Another sends scanned PDFs with handwritten notes. A third uses naming conventions that bear no relation to the internal system's records.
ReWOO is the right strategy here, because reconciliation is fundamentally a structured, repeatable workflow. The Planner already knows the steps: extract data from the external document, normalise it, find the matching internal records, match the lines, calculate the variances and generate a summary. These steps do not change from one submission to the next; what changes is the content.
The Planner maps out the full extraction and matching plan for each document, including which extraction method to use based on the counterparty's known profile (a predefined template for clean Excel files, semantic extraction for unknown formats, optical recognition with handwriting reading for scanned documents). The Workers then carry out all the data extraction and retrieval in parallel (external document data, internal accrual entries, the counterparty's historical profile, relevant rate tables) at the same time. No waiting between steps. No model reasoning after each tool call.
The Solver then gathers all this evidence and produces the reconciliation result: matched lines, variances with their root cause (naming inconsistency, rate difference, volume dispute, missing entries due to data timing) and recommended actions. Country profiles, AI-driven validation rules tailored to each counterparty's template, naming conventions and submission habits, make the Planner more relevant over time.
In production, the first-submission acceptance rate rose from about 60% to 90%, removing weeks of back-and-forth that used to stretch reconciliation timelines. And because ReWOO groups all tool execution into a single phase, the agent processes each document with about 5 times fewer tokens than a ReAct approach, which matters when you process more than 4,000 documents a year.
Why this is decisive for your SME
The gap between a conversational agent that answers questions about your data and an agent that actually does the work lies in these reasoning strategies. Most enterprise AI products use a single approach for everything and hope it holds. It works for answering a question about last quarter's revenue. It does not work for closing your books, matching invoices across four software tools, or reconciling documents from 250 counterparties in 30 countries.
- ReAct — for dynamic, unpredictable exception handling.
- Simple feedback — for fast validation loops with clear criteria.
- Reflexion — for learning from corrections and building in-house expertise.
- ReWOO — for high-volume structured workflows, where efficiency matters as much as accuracy.
Choosing the right reasoning strategy for each use case, and combining several strategies within the same agent when the problem demands it, is what separates an AI that looks good in a demo from an AI that survives month-end close. The real architecture challenge is therefore not to choose a single reasoning mode, but to enable safe transitions between modes while preserving auditability and control.
Every cognitive neuron we deploy uses the reasoning approach that fits the problem, not the one that is easiest to implement. And every reasoning step is logged, traceable and auditable, because in corporate finance, an answer you cannot explain is an answer you cannot use.
CERVOX: your operational brain. The cognitive twin that turns your scattered tools into a single, auditable decision system.