AI for accounts receivable: a practical review workflow

A useful first AI finance workflow answers three operational questions: which unpaid invoices need attention, what prevents a sensible follow-up, and what should the account owner say? The output is a reviewed worklist with draft messages. It is not a new accounting ledger, a payment prediction engine, or permission to contact customers. This narrower boundary makes discrepancies visible before they become embarrassing reminders.

Assign one finance owner to approve the source export, calculation rules, and final queue. Account managers can supply relationship context; a dispute owner can explain an unresolved delivery issue. Give each exception one responsible role and a next review date. The AI should distinguish an unavailable fact from a negative fact: no recorded promise-to-pay is not evidence that a customer refuses to pay.

The NIST Generative AI Profile identifies confabulation and data privacy among risks that need evaluation and management. In this workflow, source-linked findings, deterministic totals, and approval before sending are practical controls chosen for that risk, not a claim that NIST certifies the process.^[3]

Export only the records the reviewer is authorized to use. Include invoice ID, customer ID, currency, invoice amount, applied payments, applied credits, remaining amount, due date, status, and dispute flag. Add the export timestamp, reporting timezone, source system, and explicit aging as-of date. Where possible, include a stable reference back to the invoice. Keep bank details, card data, credentials, and unrelated customer correspondence out of the working file.

Define the row grain before uploading. One row per invoice differs from one row per invoice line or payment allocation. Summing an invoice header repeated on every line inflates receivables. Confirm whether the remaining amount already incorporates credits, customer balances, write-offs, or other adjustments; do not deduct the same adjustment twice. Document unavailable fields and stop affected calculations until finance supplies a rule.

Stripe documents amount_remaining, amount_paid, currency, due_date, and invoice status separately. Those distinctions are useful when designing an export, even if your accounting system uses different names. Map its fields explicitly rather than assuming that a column named “total” means the outstanding balance.^[1]

For the simplified example below, remaining balance equals invoice amount minus applied payments minus applied credits. Real exports may require additional adjustments, so reconcile to the accounting system’s own remaining balance and control total. Compare record counts, unique invoice IDs, currency totals, and adjustment totals. Put discrepancies in a separate exception list; do not let the model silently change an amount to make the total fit.

Credits require particular care. Stripe distinguishes a credit note that reduces an open invoice from treatment of a paid invoice, which may involve a refund or customer credit balance. Therefore, a credit document is not automatically an unapplied cash receipt, and its face value should not always be subtracted from today’s open receivables. Follow the source system’s treatment and ask finance to resolve unclear allocation.^[2]

Use currency-specific decimal precision and the provider’s documented units. Keep CAD and USD in separate totals unless finance supplies an exchange-rate date, rate source, and conversion policy. A combined number with no currency label is misleading. A negative remaining balance, missing due date, duplicate invoice ID, or payment posted after the snapshot belongs in review rather than an improvised correction.

For this guide, days overdue is the positive calendar-day difference between October 15, 2026 and the contractual due date. An invoice due today is current; future-due invoices are also current. Positive outstanding balances are grouped into current, 1–30, 31–60, 61–90, and more than 90 days. A fully settled invoice is excluded from open aging even if its historical due date has passed. These are example reporting conventions, not universal accounting requirements.

Prioritize work using visible business rules: unresolved disputes first for internal investigation, then approved undisputed overdue invoices by age and amount. A high balance can justify review without justifying a harsher message. Treat missing customer contact authorization, an active payment arrangement, a recent payment, or an account-specific collection restriction as a stop condition. Have finance approve any departure from normal account handling.

All customers and invoices in this example are fictional. Cedar Services supplies six invoice rows as of October 15, 2026. Three open CAD invoices have remaining balances of CAD1,500, CAD2,400, and CAD2,000. The last is not due until October 30. An additional USD invoice has USD750 remaining. Two other CAD invoices are settled, one through payment and one through an applied credit.

The concrete output is CAD5,900 open, comprising CAD3,900 overdue and CAD2,000 current, plus a separate USD750 open and overdue. The CAD2,400 invoice includes a documented CAD600 dispute and is held for owner review; its full balance remains in aging. CAD1,500 is the undisputed CAD invoice available for reminder review. None of these amounts is a forecast of recoverable cash.

Suppose the first draft says “CAD4,650 collectible this week.” The reviewer rejects it: 3,900 plus 750 improperly combines currencies, and no payment commitment supports the date. The correction is “CAD3,900 overdue and USD750 overdue; CAD2,400 is on dispute hold. Cash timing is unconfirmed.” This correction belongs in the review log so the next run uses the same rule.

A good reminder states the invoice reference, remaining amount and currency, source date, and a practical next step. It leaves room for a recent payment or an invoice question. It does not invent late fees, threaten legal action, disclose internal risk labels, or promise a payment plan the sender cannot authorize. Use approved contact details and the existing secure payment route; never let a generated message introduce new banking instructions.

For INV101, the draft could read: “Hello Morgan, our records show CAD1,500 outstanding on INV101 as of October 15, due September 1. Could you confirm the expected payment date, or let us know if anything needs clarification? If payment is already underway, please share the reference so our finance team can reconcile it. Thank you.” The sender checks the live balance immediately before sending and changes the wording if the account has an approved arrangement.

The worklist should show invoice reference, source timestamp, calculated age, remaining balance, hold reason, proposed action, owner, and review outcome. Link each message to its invoice rather than merely to the customer name. A reviewer can then distinguish a wrong calculation from a stale export, or an appropriate draft from a message that should never have been proposed.

Kona can prepare a workbook, explain exceptions, and draft customer messages from authorized context. This guide does not assume that it reads your inbox, updates a ledger, applies credits, collects payments, or sends reminders. Review approved outputs and execute actions in your established systems. Refresh changed invoices before use; a correct yesterday snapshot can still produce an incorrect reminder today.

Track minutes to produce and approve a worklist, corrections per reviewed invoice, percentage of drafts accepted without substantive changes, and reminders proposed for ineligible invoices. Define the denominator: accepted drafts divided by all reviewed drafts is different from accepted drafts divided by all exported invoices. Retain the same reporting cutoff and eligibility rules when comparing pilot runs.

Separately monitor dispute resolution, actual receipts, and changes in overdue balances in the accounting system. Record when receipts are allocated and whether the invoices were already scheduled for payment. An improvement after introducing AI does not establish that AI caused the receipt. Do not book draft promises or multiply overdue balances by an invented collection probability to report ROI.

During days 1–3, choose one authorized invoice cohort, document field mappings, and reproduce an existing aging report without generating customer messages. On days 4–5, test paid, credited, disputed, duplicate, missing-date, and mixed-currency cases. Finance approves the reconciliation and records which rows must stop. A failed reconciliation stops the pilot rather than becoming a narrative explanation.

In week two, generate drafts for the approved subset and have the normal account owner review every one. Record edits and review time, refresh balances before sending, and compare results with the baseline process. Expand only when reconciliation is complete, no ineligible reminders remain unresolved, and the owner agrees the queue is useful. Preserve export access and retention rules when archiving the pilot.