Use AI to review property expenses before the close

AI expense coding review is useful when it produces a short, explainable queue for a bookkeeper. It can identify missing fields, inconsistent classifications and transactions that need more context. The accountant should decide the final treatment and approve any changes to the ledger.

The aim is to reduce the effort spent finding problems. An unusual expense is not necessarily wrong, and a familiar vendor does not guarantee a correct category. A review process needs room for both facts.

This article describes operational checks, not accounting or tax classifications. Use your approved chart of accounts and the responsible accountant's rules. For the larger process, see the reporting automation guide.

Review a defined population

Begin with an extract whose boundaries are clear. Record the entity or property scope, period, posting status, included accounts and source total. Keep transaction IDs so decisions can be applied to the correct entries later.

Check that the extract reconciles to its approved source before asking AI to review it. If half the period is missing, a tidy exception sheet will give false reassurance. Keep credits and reversals visible rather than dropping negative amounts to make the spreadsheet simpler.

Use the smallest information set that lets the reviewer do the job: transaction ID, date, vendor, amount, currency, current category, relevant property reference and supporting description. Provide controlled access to receipts when needed. Avoid copying unnecessary cardholder, guest or bank details into a general-purpose tool.

Your accounting system may already flag anomalies. Sage describes machine-learning outlier detection within its general ledger offering. Review the existing capabilities and their evidence trail before adding another layer that flags the same transactions.

Keep rules and suggestions in separate columns

A deterministic rule can identify a missing required property code. A pattern-based suggestion might identify an expense coded differently from similar entries. These deserve different labels and different review expectations.

Use categories such as "required field missing," "approved rule conflict," "possible inconsistency" and "insufficient evidence." Do not turn every result into a confidence percentage. Reviewers need to know why a row is here and what would resolve it.

Write rules with the accountant. For each rule, record the condition, permitted exceptions, effective date and owner. A merchant-based rule should be used only where that merchant reliably represents the same approved treatment for the relevant transactions.

QuickBooks bank rules can use transaction descriptions, bank text and amounts. Those conditions are useful automation inputs, but someone still has to decide whether the rule is appropriate for the business's expenses.

Keep a record of rule changes. If an accountant revises a classification policy, the model should not continue treating older coding as the current answer.

A merchant name is not enough context

A hardware supplier can sell consumables, replacement equipment and materials for different properties on one receipt. A payment processor's description may identify the platform rather than the actual service. Similar merchant strings may also belong to unrelated vendors.

Use invoice line items, the service period and the supporting job or contract when they are available. Navan's account of its categorization system describes combining transaction information with receipt data and other context. Its reported results concern its own system; they do not establish the accuracy of your review process.

Missing context should generate a focused question. "Which property received these materials?" is more useful than "Please clarify this expense." If a receipt mixes purposes, the reviewer may need an allocation decision. The tool should request the basis instead of making an equal split by default.

Keep questions with the transaction record. Otherwise, the answer may remain in someone's inbox while the next reviewer asks the same thing again.

A worked review sheet

The following fictional rows illustrate review outcomes. The suggested actions do not prescribe account codes or accounting treatment.

The sheet should include the original coding, the proposed question or change, source references and the review decision. Preserve the initial flag even when the reviewer rejects it. That gives you evidence about the tool's usefulness.

For E-102, the accountant may find a valid exception. Mark it "no change, exception documented" and link the reason. Don't erase the row to make the review's apparent accuracy improve.

For E-103, a model could produce a plausible category immediately. That would skip the actual problem: the business has not supplied enough facts for the treatment to be decided. The useful output is the missing-evidence request.

Let approved corrections return through the accounting process

Keep the review layer read-only during the pilot. Once a bookkeeper approves a correction, apply it through the normal accounting workflow and record the resulting transaction or adjustment reference.

Avoid editing an exported spreadsheet and treating that as a ledger correction. The change needs to reach the authoritative system, with the required permissions and accounting review. If the period is closed, follow the approved process for changes rather than reopening it automatically.

The month-end close guide explains how these exceptions interact with release gates. The invoice approval guide covers a different decision: whether an obligation is authorized. Correct coding alone does not approve payment.

If you later permit approved writes, require a specific record, approved before-and-after values and a check that the source has not changed since review. A second reviewer may otherwise correct a transaction while the automation still holds an older version.

Measure false alarms and missed errors

A useful evaluation examines both the flagged queue and a sample of the rows the tool passed over. Looking only at accepted suggestions measures how convincing the flags are, not whether the review finds the important errors.

Suppose a hypothetical test contains 120 transactions. The tool flags 24; the accountant confirms that 15 need a coding correction. The correction yield is 15 divided by 24, or 62.5%. The other nine may include valid expenses, missing-evidence questions or unhelpful alerts. Keep those outcomes separate.

Now sample the 96 unflagged transactions. If the accountant reviews 20 and finds two coding problems, those misses need investigation. Do not claim that the entire unflagged population has exactly a 10% error rate from that small sample. Use it as evidence that the process is missing a pattern, then expand the review appropriately.

Compare active review time with the previous process. Include the time spent obtaining documents, dismissing weak alerts, correcting entries and maintaining rules. A shorter queue can still consume more time if every explanation is vague.

Use the review to fix recurring causes

Group confirmed issues by cause after each cycle. Missing property references may call for a better purchasing form. Repeated merchant ambiguity may need a vendor mapping. A recurring classification disagreement may need a written accounting rule.

Feed approved outcomes back into the process carefully. A single accepted exception should not become a universal rule. Keep examples tied to their circumstances and effective dates.

Start the next cycle with the fixes that remove repeated questions. The vendor spend analysis guide shows how cleaner classifications and vendor records can then support more useful purchasing decisions. Retain human review wherever the evidence or treatment remains uncertain.