AI Accounting Entry Classification: Rules, Suggestions, Review

AI Accounting Entry Classification: Rules, Suggestions, Review

AI accounting entry classification works best when the job is split into three layers. Fixed rules handle what is repetitive and unambiguous, the AI suggests an account and description for the ambiguous cases, and the accountant checks whatever carries risk or low confidence. Every entry carries the source of the decision, the reasoning and who approved it, and that is what gives you traceability.

Key takeaways

• There is no single AI step. There are deterministic rules, model suggestions and human review, each with its own role and limit.
• Fixed rules come first, because they are predictable, cheap to audit and do not change their answer from one day to the next.
• The AI only suggests within the company's chart of accounts and returns a short justification. It never creates accounts and never writes to the system on its own.
• The accountant sets the criteria, reviews the exceptions queue and decides what can become a rule.
• Without a log per entry (source, rule version, suggestion, final decision), the process is not auditable, no matter how good the suggestions look.

Why not hand the whole chart of accounts to the AI?

The temptation is simple: export the bank statement, paste in the chart of accounts and ask the model to classify everything. In a quick test, the result looks good. The problem shows up later, when the same supplier lands in different accounts in different months, when a new account appears without approval, or when nobody can explain why an entry went to a given account.

A language model is good at interpreting messy text, such as an abbreviated statement line, a card descriptor or a truncated supplier name. It is worse at staying strictly consistent across thousands of items and at following internal policies that are not written down anywhere. That is why the division of roles matters more than the choice of model.

Anthropic's documentation on building agents makes a useful distinction between workflows, where the paths are defined in code, and agents that decide their own path. For accounting, the prudent choice is to start with the defined workflow: fixed steps, with the model called only where judgment is needed.

Layer one: which entries should a fixed rule handle?

A fixed rule covers anything the accountant would always answer the same way without thinking. There is no AI in this layer, and that is an advantage: the result is reproducible and easy to explain.

Good candidates for rules:

• Recurring bank fees with a standard description.
• Suppliers identified by tax ID (CNPJ in Brazil) that always belong to the same account, such as the office electricity or internet bill.
• Entries coming from electronic invoices (NF-e) where the nature of the operation and the line items are already structured in the XML.
• Transfers between the company's own accounts.
• Taxes and payment slips with a recognizable barcode or revenue code.

A well-written rule has an identifier, a condition, a destination account, a creation date and an owner. Prefer conditions based on structured fields (tax ID, code, exact recurring amount) over conditions based on free-text fragments, which produce false positives. If a text fragment like "gas station" sends everything to fuel, a convenience store purchase will end up in the wrong place without warning.

Rules also need versions. When the accountant changes a rule, entries already classified should keep pointing to the previous version, and only new entries use the current one. This prevents you from rewriting history without noticing.

Layer two: what should the AI suggest, and with what data?

What is left after the rules is the ambiguity queue: vague descriptions, new suppliers, purchases that could be an expense, a cost or an asset. Here the AI acts as a suggester, not a decision maker.

The model should receive a minimal, controlled package:

• The entry description, amount and date.
• The supplier or payee, when there is one.
• The closed list of allowed accounts, with one sentence explaining each.
• A few entries already approved by the accountant that resemble the current case.
• The written internal policies, such as the threshold for treating an item as a fixed asset.

It should return a fixed format: suggested account (from the list only), confidence level in simple categories (high, medium, low), a justification in one or two sentences, and a field to say when information is missing. An explicit "I don't know" is worth more than a confident wrong answer. If the receipt or invoice is missing, the right suggestion may be to ask for the document rather than classify.

Two practical safeguards. First, validate the output in code: if the returned account does not exist in the chart, the entry goes back to the human queue. Second, treat the text of entries as data, not as instructions. Descriptions come from third parties, and a malicious or merely odd description must not change the model's behavior. The OWASP guidance on prompt injection in applications built on language models covers this risk.

If the source documents are invoice and payment slip PDFs, extracting the fields is a separate step with its own check. The article on extracting data from PDFs with AI describes how to separate reading the document from making the decision.

Layer three: when does the accountant need to check?

Human review should not mean reviewing everything, and it should not be an automatic rubber stamp. It needs clear criteria for what must go through the accountant. A simple decision guide:

• Low confidence or a "missing information" flag: always goes to review.
• A supplier never seen before: review, with the decision saved so it can become a rule if the supplier repeats.
• An amount above the limit set by the accountant: review, even with high confidence.
• Operations with tax impact, related parties, partners or payroll: mandatory review, no exceptions.
• Disagreement between the AI suggestion and an existing rule: review, because it signals an outdated rule or an error.
• High confidence, known supplier and low amount: periodic sampling instead of item-by-item review.

Sampling is the delicate point. It is only honest if the accountant also reviews a sample of what the AI classified with high confidence, because that is where silent errors hide. Record the correction rate of that sample over time and use it to decide whether the threshold can go up or should come down.

When the accountant corrects a suggestion, the correction is valuable information. It can become a new example for the model's package or a new fixed rule, always by the accountant's decision, not the system's. Professional responsibility for the bookkeeping stays with the accountant. The AI reduces typing and triage, but it does not transfer that responsibility. For a broader view of what should stay with people, see what not to delegate to AI in your business.

How do you get traceability on every entry?

Traceability means being able to answer three questions months later: who classified it, based on what, and who approved it. To do that, each entry should keep a record with fixed fields:

• Entry identifier and source document identifier.
• The step that decided: rule, AI suggestion or manual adjustment.
• Rule identifier and version, when a rule decided.
• For suggestions: model used, version of the instruction set, suggested account, confidence and justification.
• Final decision, who made it and when.
• Reason for the correction, when the accountant changed the suggestion.

Store this in a separate log table that the workflow only appends to and never overwrites. The observability concepts from OpenTelemetry (logs, metrics and traces) help you think about how these events connect, even if the implementation starts as a well-controlled spreadsheet or a simple database.

On privacy: statements and invoices contain personal data of partners, employees and individuals. Send the model only what is necessary, mask personal tax IDs and bank details that do not affect the classification, and define how long the log is kept. If the model runs outside Brazil, it is worth reading about international data transfer with AI under LGPD. The ANPD (Brazil's data protection authority) website is the official reference for guidance.

Illustrative scenario: one month of reconciliation at a services company

Imagine a services company with a mid-sized monthly bank statement, prepared by someone in finance and reviewed by an external accountant. This scenario is illustrative and unrelated to any real client.

The workflow receives the statement file and the invoices for the period. The fixed rules recognize fees, transfers between the company's own accounts, tax payments and recurring suppliers by tax ID. Those entries are classified and recorded in the log with the rule identifier.

Everything else goes to the AI. A debit with an abbreviated description from an unknown supplier gets a suggestion of a third-party services account, medium confidence, and a justification that the name suggests a service provider but the invoice is missing. Because it is a new supplier and confidence is not high, it goes to the accountant's queue. The accountant requests the invoice, confirms the account and flags the supplier to become a rule.

The following month, that supplier already falls into layer one. The human queue got shorter because of the accountant's decision, not because the model "learned" on its own. At close, the accountant also reviews a sample of what was classified with high confidence, records the errors found and adjusts thresholds and rules.

How to start: map, limit, pilot and hand over

The method we use in applied AI projects follows four steps, and it fits this case well.

• Map: document how classification is done today, which systems and documents are involved, who decides, and what the baseline is for time and rework. Without that picture, you cannot tell whether things improved.
• Limit: define which data the model sees, which accounts it may suggest, and that it never writes directly to the accounting system. The output is a suggestion in a queue, not an entry.
• Pilot: pick one small, real flow, such as a single bank account or one type of expense, with a complete log and a metric agreed with the accountant, such as the share of suggestions accepted without correction.
• Hand over: deliver the documentation of the rules, the review criteria and the log, and decide with the accountant whether to expand, adjust or stop.

To measure suggestion quality before switching the flow on, build a test set of entries that were already classified and approved, and compare the model's suggestion with the accountant's decision. OpenAI's evaluation guide describes this logic of testing model-based systems against known cases, and the principle holds regardless of vendor. Repeat the test whenever you change the model, the instructions or the chart of accounts.

If the flow touches decisions about people, such as pay or individual payments, check the right to review provided by LGPD, explained in automated decisions and Article 20.

Frequently asked questions

Can the AI post directly to the accounting system without review? It is not recommended at the start. The safest design writes the suggestion to a queue and only moves it into the system after a rule applies or a person approves. Over time, the accountant can authorize direct posting for low-risk categories, while keeping sampling and the log.

Do I need to train a custom model on the company's history? Usually not. For this kind of task, a general model with the chart of accounts, written policies and approved examples in the context package is normally enough, plus validation in code. Training or fine-tuning a model is a later step, only if testing shows the context is not enough.

How do I stop the AI from inventing an account that does not exist? Give it a closed list of accounts and validate the response in code before accepting it. If the returned account is not on the list, the entry goes automatically to the accountant's queue, with the error recorded in the log.

Does this process replace the accountant or the accounting firm? No. It reduces triage and typing, but criteria, exceptions and professional responsibility stay with the accountant. The gain is in spending their time on the cases that need judgment, with a clear history of each decision.

Sources

• Anthropic: Building effective agents
• OpenAI: evals guide
• OpenTelemetry: observability concepts
• OWASP: prompt injection prevention