Mirek Riedewald

More Than Meets the Eye: Why Invoice Coding Is an AI Grand Challenge (February 15, 2026)

TL;DR

Invoice coding may look like a dusty accounting problem, but on closer inspection it is both practically complex and intellectually demanding. Like a self-driving car navigating an unstructured environment, invoice coding must interpret highly variable inputs, combine natural language understanding with customer-specific business rules, and operate despite incomplete or inconsistent ground truth. The margin for error is small because real money and legal compliance are at stake. Fortunately, innovative startups like PredictAP are pushing beyond traditional OCR-heavy approaches toward true AI-driven automation.

Full Post

Why Invoice Coding Seems Simple

You do not need to be an accountant to understand the basic idea of invoice processing. A vendor bills a customer for goods or services, and the vendor expects to be paid. Most of us have paid a bill by looking at an invoice, identifying the payee and amount, and initiating a payment from a bank account. With modern AI's ability to understand documents, it might seem reasonable to assume that it would be straightforward to automate this process in enterprise settings. But that intuition breaks down quickly once you look at how invoice processing actually works inside organizations.

Why Enterprise Invoice Coding Is Fundamentally Different

Consider a real estate management company that processes 100,000 invoices per year across hundreds of vendors and dozens of properties. Each invoice must be coded for accounting and reporting purposes. That includes identifying the correct vendor using an internal vendor code, selecting the correct property using an internal property code, assigning one or more general ledger (GL) accounts depending on the nature of the expense, and capturing additional fields such as invoice date, due date, tax breakdowns, and notes.

Unlike an individual whose logic might simply be "pay all bills from my checking account," an AP clerk must follow complex, customer-specific rules to ensure coding is accurate and consistent across the organization. This is where AI can deliver real value, when done right. It can automate repetitive work such as identifying vendors, suggesting properties, and proposing likely GL accounts. It can also learn historical patterns to improve consistency and flag anomalies or potentially fraudulent invoices. But this raises a deeper question: why isn't invoice coding just a matter of reading the invoice?

OCR Fields Versus Prediction Fields

Only a small fraction of the required data actually appears explicitly on the invoice, therefore OCR and templates are not sufficient for invoice coding. They may work for fields like invoice date and vendor name, which are usually visible on the document and can be extracted using OCR and modern document understanding tools. These are OCR fields.

Many of the most important fields, however, are customer-specific and almost never appear on the invoice. Vendor codes, property codes, and GL accounts are internal constructs. The vendor issuing the invoice does not know the customer's internal chart of accounts or coding structure. These are prediction fields. Their values must be inferred from invoice content, historical patterns, and the customer's unique practices.

Some fields fall in between. A due date might be printed on the invoice, or it might need to be calculated based on payment terms. An invoice number might be visible, or it might need to be synthesized based on internal policy. The boundary between extraction and inference is blurry, and managing that ambiguity is central to the challenge.

Why Historical Data Is Not Enough

At first glance, this seems like a classic supervised learning problem. Organizations have large volumes of historical invoices where both the original document and the final coded output are available. Why not just train a model on that data? The problem is that the ground truth is often incomplete and inconsistent. Different AP clerks may code similar invoices differently. Even when you see the final coded invoice, you usually do not see the reasoning behind the decisions.

Imagine an invoice listing tea, cookies, and plates, each at ten dollars. If the final coding shows twenty dollars allocated to account A1 and ten dollars to account A2, the mapping from line items to accounts is still unclear. Did tea and cookies go to A1 and plates to A2? Or was there some other rule? Without understanding the underlying policy or seeing many additional examples, the model cannot reliably infer the logic. This ambiguity makes learning from historical data far more difficult than it initially appears.

Why Off-the-Shelf LLMs Are Not Enough

Large language models (LLMs) are excellent at understanding text and extracting information. They can often identify vendor names, addresses, dates, and line items with impressive accuracy. But they are not trained on any specific customer's vendor list, property structure, or chart of accounts. They have no built-in knowledge of how your organization encodes its financial data. Out of the box, they can handle what meets the eye. They cannot handle what is specific to your business.

There are two main ways to bridge this gap. One is advanced prompting, in particular Retrieval-Augmented Generation (RAG), where carefully selected examples of coded invoices and explanations are provided so the model can follow the customer's logic. Its success depends heavily on the quality and relevance of the (usually fairly small number of) examples included in the prompt. The alternative is fine-tuning, where the AI model is trained on large volumes of customer data. That approach can work, but it is computationally expensive, slow to update, and difficult to balance: Over-customize and the model loses general language ability. Under-customize and it fails to learn the customer's coding rules. This is why invoice coding is not a plug-and-play AI problem.

Why This Is Closer to Self-Driving Cars Than to Data Entry

Invoice coding may sound mundane, but structurally it resembles far more obviously complex AI challenges.

Invoices can contain a combination of typed text, handwritten notes, and images, such as the vendor's logo. Layouts vary widely. Some are clean and structured. Others rely on visual cues such as spacing, indentation, and line placement to convey meaning. OCR errors, layout ambiguity, and document variability all compound the difficulty.

Customer-specific complexity adds another layer: Industry practices differ. Internal policies differ. Regulatory environments differ. Contracts introduce context that is not fully visible on the invoice itself. Some invoices only make sense when interpreted within the framework of an ongoing agreement. There may be special rules for late fees, remittance vendors, or how shared costs should be split across properties. And as with autonomous systems, the stakes are high. Mistakes affect financial accuracy, audit outcomes, and legal compliance.

Final thoughts

Invoice coding cannot be solved with generic models and naive supervised learning. It requires deep domain understanding, thoughtful system design, and human ingenuity to build AI pipelines that can adapt quickly and cost-effectively to each customer's unique practices. When a vendor claims to offer an AI-powered invoice coding solution, ask the hard questions. How do they predict non-OCR fields like vendor codes, property codes, and GL accounts? How do they determine how line item costs should be aggregated and split across accounts? How do they adapt when customer practices evolve over time?

The answers to those questions reveal whether you are looking at surface-level automation or a genuinely advanced AI system for "hands-free" invoice capture and coding.

I am happy to discuss research and consulting opportunities, collaborations, etc. It is perfectly fine to send me reminders if I do not respond in a timely manner: I receive a lot of emails and sometimes important messages end up in spam folders.

• m.riedewald@northeastern.edu
• +1 (617) 373-4766
• Khoury College of Computer Sciences
  202 West Village H
  Northeastern University
  360 Huntington Ave
  Boston, MA 02115