AI to Write Rules, or AI to Make Decisions?

The Manual Reconciliation Problem: The Financial Close Needs AI, But Where?

Last April FloQast, an American maker of accounting software, published something unusual: a detailed engineering post on Amazon Web Services’ machine-learning blog, co-authored with AWS personnel, explaining precisely how its AI-powered transaction-matching feature works under the hood. The post described cloud infrastructure, model selection, and the specific technique (generating matching rules from user-supplied examples) that powers its AutoRec product. It was, by any measure, a credible piece of technical writing. It was also, whether intentionally or not, throwing down the gauntlet to its competitors. JustPerform from insightsoftware has taken up the challenge. The JustPerform team doesn’t dispute FloQast’s engineering prowess. Rather, it argues that the architecture FloQast has so transparently described has a fundamental limitation, one that will matter increasingly as finance teams grow in complexity. It’s a limitation that the JustPerform approach avoids entirely. The difference in approach, and technique, is about where in a reconciliation workflow artificial intelligence is likely to be most effective.

Rules-Based Matching: How AI-Generated Rules Work (And Their Limitations)

FloQast’s matching system works in two stages. In the first, an accountant selects a handful of example transactions (a bank entry on one side, a general-ledger entry on the other) and clicks “Generate AI Rule.” The model, running on Anthropic’s Claude 3.5 Sonnet via Amazon Bedrock, reads those examples and produces a matching rule in coded form. In the second stage, the rule executes against the transaction data and finds further matches. The AI is not involved in stage two. Its work ends when the rule is saved. This is a perfectly respectable engineering choice. Deterministic rules are fast, auditable, and easy to explain. An auditor can read a rule and understand immediately why a given transaction was matched. For a finance team managing a handful of stable account types with predictable transaction patterns, such an architecture does precisely what it promises. The trouble is that finance teams rarely stay simple. Growth adds legal entities. Acquisitions add enterprise-resource-planning systems. Vendors get acquired and rebranded; cost centers are restructured; new subsidiaries bring unfamiliar chart-of-accounts conventions. Each of these events is, in a rule-generation system, a rule-rewrite waiting to happen. The rules do not learn from new transactions they encounter after being written, because the AI is no longer in the loop. They either misfire or stop matching entirely, and someone must notice, diagnose, and repair them, typically under month-end pressure, against a clock. JustPerform views this as the maintenance cost that doesn’t appear on the invoice. Rule libraries, invisible in headline automation metrics because upkeep happens between close cycles, quietly consume the time of the finance team whose liberation from drudgery was supposed to be the whole point of automation. FloQast cites a 38% reduction in reconciliation time and a 23% reduction in audit-process duration. Both figures may be accurate. But neither captures what the team spends keeping the rules current.

Adaptive Matching Architecture: Why Confidence Scores Matter

JustPerform’s alternative is architecturally different in one crucial respect: its AI operates at match-decision time, not at rule-writing time. When a bank entry requires reconciliation against a ledger entry, the model evaluates that specific transaction against available candidates and produces a confidence score, a rating of one to three, reflecting its certainty about that particular match. There are no pre-written rules. The AI is, in effect, continuously present during the close itself. That distinction carries practical weight. A rule either fires or it does not: when a transaction falls into a grey zone, e.g., an amount that is close but not exact, a description abbreviated differently this month, a timing difference straddling a period boundary, it lands in the unmatched queue indistinguishable from a genuine discrepancy. The queue tells a controller that something needs attention; it does not say which items are near-misses amenable to quick human review and which require serious investigation. At low volumes, this is a nuisance. Across hundreds of accounts and thousands of transactions per close cycle, it becomes a material drag. A confidence score resolves this. A rating of three means the AI evaluated the match and found it clean. A rating of one means it found a candidate that it is flagging for review, and it can say why. Controllers can triage by signal quality rather than investigating everything uniformly. Auditors see not just that matches were made, but the distribution of certainty across the population: a richer, and arguably more honest, picture of reconciliation quality than a binary match-or-miss log. These confidence-driven controls represent best practices in achieving reconciliation accuracy and auditability at scale across complex organizations. For chief financial officers, the appeal is subtler but significant. Rule-generation systems require continuous human investment to remain accurate as the business evolves; adaptive systems, in theory, do not, because there are no rules to rewrite. This approach supports advanced reconciliation architecture that maintains reconciliation accuracy and auditability across evolving business processes. JustPerform expects its users to enjoy up-to-95% autonomous-completion rate for bank reconciliation and an 80-to-90% reduction in reconciliation time. This is not a one-time gain requiring maintenance to sustain, but a steady-state output of an AI making live decisions rather than executing pre-written logic.

Finally, A Finance System Made for Humans

Learn More

The Future of Reconciliation: Agentic at Setup or Agentic at Runtime?

FloQast's AWS post describes its workflow as being orchestrated by Amazon Bedrock Agents, and the term is accurate in its technical context: Bedrock Agents is an AWS service that coordinates multi-step tasks across tools and data sources. It is, however, a mechanism for sequencing the AI's work during setup, not a description of AI operating autonomously within the reconciliation process itself. However, the term "agentic" has a second, increasingly important meaning in enterprise software. It describes AI that acts as a continuous participant in a workflow rather than as a one-time contributor to its configuration. JustPerform uses "agentic" in this second sense. Lineos, insightsoftware's agentic AI agent, configures the reconciliation process and goes on to participate in every matching decision. It evaluates each transaction and assesses its own accuracy by returning a confidence score. The close is not a system executing instructions the AI wrote earlier; it is a system in which the AI is still present, still reasoning, still accountable for each outcome. Neither use of the word "agentic" is wrong on its own terms. But they describe fundamentally different things. When evaluating AI-driven reconciliation tools, it is worth asking not just whether a vendor's AI is agentic, but when in the process it operates, and what it is empowered to decide.

What to Choose: Rules-Based vs Adaptive Matching Architectures

FloQast’s decision to publish its engineering in such detail was, in one reading, an act of confidence. The company built something real, understands how it works, and is willing to explain it publicly to an audience of accounting leaders. That transparency is worth respecting, and JustPerform has tried to meet it at the same level, engaging with the architecture on its own terms rather than resorting to marketing evasion. But the post also marks a moment. When a leading reconciliation vendor is explaining few-shot classification and retrieval-augmented generation to accountants in an AWS engineering blog, the underlying technology has ceased to be a differentiator by itself. Every serious vendor in this space is building on foundation models. The question that separates them is not whether they use AI, but where in the process it operates, and what it is empowered to do when it gets there. FloQast’s answer: at rule-writing time, with deterministic execution thereafter. JustPerform’s answer: at every transaction, with a decision and a confidence score each time. Both architectures have genuine merits. The rule-generation model will continue to suit organizations with stable, well-defined account types and teams that are comfortable managing rule libraries. The adaptive model will appeal to those whose businesses change faster than their rule libraries can keep up. The adaptive approach supports intelligent matching and exception handling that adapts continuously as organizational structures and transaction patterns evolve.

The Missing Piece of Enterprise Planning Processes

Learn More The direction the category is moving, however, is not ambiguous. Fully agentic finance operations, where AI participates continuously in the work rather than merely assisting with setup, are the destination every serious vendor is navigating toward, at different speeds and by different paths. The confidence-scoring model, the audit trail built from decisions rather than rule logs, the close process that does not degrade when the business evolves: these are not differentiating features waiting to become standard. They are, in all likelihood, the architecture of reconciliation in the future. If your team is navigating the limitations of rule-based reconciliation, JustPerform from insightsoftware offers an adaptive, AI-driven alternative. Contact us to request a demo. Or start with 20 complete autonomous reconciliations on the free plan; no credit card required.

Learn More About JustPerform