Exception-Based Accounting

A business processes 10,000 monthly receipts, and matching rules link most to open invoices while 250 unmatched items reach an analyst for review. The analyst checks those exceptions rather than retyping every successful match.

Define what a normal transaction looks like, such as a valid customer, amount, currency, reference and authorised account, with rules that reflect real processes rather than an arbitrary threshold that hides small repeated errors. Different exceptions call for different owners: an unmatched bank receipt may go to cash application, an invoice price difference to purchasing and an unexpected journal entry to a controller.

Routing reduces the risk that every issue lands in one generic inbox. Oracle's reconciliation guidance describes automated matching and review workflows for unmatched items, and while product mechanics differ, the general idea is to separate routine matches from cases needing investigation.

A newer Oracle exception-management feature highlights unusual transactions, missing expected activity and changes to vendor information, but the vendor describes it as dependent on sufficient history and configuration, and it does not replace human judgment or exist in every account. Design rules with tolerances, so minor rounding can be handled automatically if policy allows while changed bank details or large unexplained balances deserve escalation.

Review tolerances after operations or fraud patterns change, and preserve evidence for automatic matches, including source transactions, rule version, match date and exceptions. An illustrative exception rate is items flagged for review divided by items processed in the same period, so 250 of 10,000 gives 2.5%, but a lower rate is not necessarily better if the rules are missing true errors.

Measure accuracy, not just volume, by reviewing a sample of items that passed automatically to estimate false negatives and inspecting dismissed exceptions to detect rules that waste staff time. Prioritise by risk and age, since a small unexplained balance that repeats for six months may matter more than a large timing difference that clears the next day.

Keep close deadlines visible, because an exception found after financial statements are released can require correction or explanation, and earlier detection helps avoid a month-end scramble without promising a perfect close. Separate "exception resolved" from "exception hidden": a reviewer may mark a case as a legitimate timing item with evidence, correct the entry or escalate it, and deleting the alert without a reason weakens the control.

Reconcile totals as well, since a rule that matches individual transactions must still account for all source entries and ledger entries, and missing files or duplicate loads can escape a process that only reviews visible records. Protect duties, so the same person should not freely change matching rules, approve exceptions and release related payments without oversight, and small firms can use owner review or periodic independent sampling.

Learn from patterns, since a recurring tax-code error may need a supplier master change rather than a monthly manual adjustment, and avoid blind trust in unusual-activity models because a legitimate new product can look anomalous while repeated errors can become a learned norm. Tell managers whether a reported balance is final, estimated or still under investigation; for an owner, exception-based accounting puts attention where it has the most value, provided ordinary transactions remain traceable, important misses are caught, and exceptions have clear owners and resolutions.