Thursday, 15 October 2026

AI and Invoice Processing

When AI Gets the Numbers Right but the Meaning Wrong: The Risks of AI in Accounting and Auditing


ChatGPT with Stephen D Green, October 2026


Artificial intelligence is increasingly being used to process invoices, check tax calculations, reconcile payments and support financial audits. These systems can save time and identify errors, but an important weakness remains: an AI can perform a calculation correctly while misunderstanding the financial information on which that calculation depends.

Consider a simple example.

An invoice issued in Abeesee in June 2024 shows a taxable amount in the currency code ABC, with the tax payable displayed in US dollars (USD). At the time the invoice was issued, ABC represented Abeesee's national currency. However, when the AI model was trained, it had encountered the same code associated with a different currency.

The AI extracts the figures, applies the stated tax rate and calculates the expected total. Its arithmetic is flawless. Yet it interprets ABC using the wrong historical meaning, potentially applies an inappropriate exchange rate, and rejects an invoice whose tax amount is correct.

The problem is not necessarily the mathematics. It is the assumption behind the mathematics.

The hidden weakness: knowledge is not automatically corrected

Large language models learn from training data and statistical patterns. They do not ordinarily maintain a fully verified, continuously updated ledger of facts. When new information contradicts what a model previously learned, that earlier information does not automatically disappear.

A model may therefore produce a plausible answer based on an outdated currency definition, a superseded tax regulation or an obsolete accounting convention. Even when it recognises that a document is unusual, it may fill gaps with an assumption rather than establish the correct interpretation.

This creates a particular risk in finance, where seemingly minor details—currency codes, invoice dates, jurisdictions, tax classifications and exchange-rate conventions—can determine whether a payment is correct.

Why this matters for business payments

In a payment workflow, an AI's approval may be treated as evidence that an invoice has been checked. But if the underlying interpretation is wrong, the system can give a false sense of security.

Potential consequences include:

  • Incorrect tax calculations and tax reporting.
  • Overpayments or underpayments caused by inappropriate currency conversions.
  • Inaccurate accounting entries and foreign-exchange adjustments.
  • Reconciliation failures between invoices, bank payments and general-ledger records.
  • Audit findings that go undetected because the checking process relies on the same incorrect assumption.

The danger is not limited to unusual currencies. Tax rules change, companies merge, suppliers change their legal identities, and accounting standards evolve. A system that treats yesterday's knowledge as today's truth can make errors at scale.

Correcting the answer is not the same as correcting the system

Suppose an accountant tells the AI that its interpretation of ABC is wrong. The model may correct its answer in that conversation, but this does not necessarily update its underlying trained knowledge, its external reference database or the rules used in subsequent invoice checks.

Unless the correction reaches the appropriate source of information, the same error may recur when another invoice is processed.

This distinction is crucial for auditing. A correction that exists only in a conversation is not a reliable control. Businesses need to know whether the authoritative record was updated, whether the revised information was used in later transactions, and whether earlier transactions require review.

A safer approach: verify the evidence, not just the arithmetic

A robust AI-assisted accounting process should establish the meaning of financial codes at the invoice date, consult authoritative currency and tax references, apply the relevant accounting rules, and independently recalculate the figures using deterministic software.

It should also flag uncertainty rather than silently inventing missing information. Where appropriate, it should retain an audit trail recording the source data, exchange rate, calculation method, assumptions, correction history and approval decision.

Importantly, the original information should not always be deleted. A currency code may have had one valid meaning in an earlier period and another later. The system should preserve historical accuracy while ensuring that the correct interpretation is applied to each transaction.

Human review remains important for exceptions, ambiguous documents and material financial decisions. AI can help identify and investigate discrepancies, but its confidence should never be mistaken for proof.

Conclusion

AI can be an extremely useful tool in business payments, accounting and auditing, but reliable financial control requires more than a convincing answer or a correct calculation.

The central question is not simply whether the AI can calculate the tax. It is whether the AI has established that it is calculating the right tax, using the right currency, the right rules and the right information for the relevant date.

In finance, an error that looks mathematically precise can still be fundamentally wrong. The objective should therefore be to build AI systems that are evidence-based, time-aware, transparent about uncertainty and independently verifiable—not systems that merely sound certain.

Saturday, 3 October 2026

AI involvement in architecting electronic business documents

 This is armchair speculation, but if AI starts designing electronic invoice variant schemas, such as extension schemas for UBL or PEPPOL, it might end the usefulness of electronic invoicing for VAT or sales tax revenues. It makes sense to find ways to accommodate what seems the inevitable rise of AI generated XML schemas, such as those for standard XML electronic invoices. The core schemas could be human-maintained, human-governed, while keeping track of changing requirements of invoicing, or industry, or national and regional variations, this might be put into the ‘hands’ of AI. The AI could be taught the constraints of keeping the core intact and rarely or never changed, while it is ‘allowed’ (or in future it ‘allows’ itself) to produce extensions to this core to cater for inevitable variations beyond the core. It is easy enough for humans to understand this, and therefore for humans to know how to maintain the overall governance of this kind of architecture, and maintain the core itself, including its ongoing standardisation. I suggest the main weakness is the distrust humans have in AI. The invoice itself is primarily a document for maintaining human scrutiny of business transactions, including prominently the collecting of taxes on these transactions. Humans must trust the overall business and public service revenue collection involved in the use of invoices. If it becomes the norm to treat AI like humans have treated innovations such as genetically modified, or pesticide-treated crops, where ‘GMO-free’ or ‘organic’ labelling is something many consumers will pay extra to see on products and services, and thus ‘AI-free’ gains traction, it might become politically and economically impossible to persist AI involvement in invoicing, including in its architecture and extension provision, without providing AI-free options. How far these options will go in ensuring AI is out of the loop remains to be seen. Will it mean any involvement of AI, even in deciding the architecture, destroys public trust? That could become an increasingly costly challenge. 

Friday, 2 October 2026

‘AI-free’ public services? Including Tax invoices?

 If “AI-free” becomes a valued consumer and business attribute, private companies can respond by creating an AI-free product. But a revenue-collecting public system has a different problem: it has to remain usable by people who object to AI, while also maintaining standardisation, auditability and compliance.

VAT invoicing is a good example because several requirements can pull in different directions:

  • Standardisation: invoices need sufficiently consistent structure for automated processing.
  • Interoperability: businesses need to exchange invoices with different systems.
  • Compliance: the tax authority needs reliable records.
  • Automation: government has an incentive to reduce processing costs.
  • AI adoption: AI could make schema maintenance, validation, mapping and exception handling cheaper.
  • AI refusal: some businesses may eventually regard AI-free operation as a legitimate requirement.


— ChatGPT, prompted by Stephen D Green, October 2026


Thursday, 23 July 2026

Saturday, 11 July 2026

Suggested (AI-generated) prompt for a conversation about Electronic Invoicing formats

 Suggested (AI-generated) prompt for a conversation about Electronic Invoicing formats: 


I want to continue a deep technical and historical discussion about electronic invoicing standards, especially the relationship between South Korea, the UK, EU e-invoicing standards, UBL, PEPPOL, EN 16931, XML evolution, and tax modelling.


Please treat the following as prior context and continue from it rather than restarting from basics.


---


MAIN TOPIC


We are analysing how different countries approached electronic invoicing:


- South Korea

- Vietnam

- United Kingdom

- European Union


with particular attention to:


- XML-based e-invoicing

- tax authority reporting models

- public-sector procurement invoicing

- UBL

- PEPPOL

- EN 16931

- tax modelling approaches

- migration from XML toward APIs/JSON


---


SOUTH KOREA CONTEXT


South Korea developed a national electronic tax invoice system based around the National Tax Service (NTS) Electronic Tax Invoice XML format.


Important points:


- Korea's model was primarily designed for tax administration, VAT compliance, fraud reduction, and national reporting.

- It was not originally designed as an international procurement interoperability standard.

- It is closer conceptually to systems such as Italy's FatturaPA than to PEPPOL BIS Billing.

- It is deeply embedded in Korean business processes and is unlikely to disappear quickly.


The Korean private sector uses NTS XML extensively because it is the authoritative tax invoice format.


Large enterprises often also use:


- EDI

- SAP IDoc

- cXML

- proprietary XML

- procurement platforms


but ultimately map to NTS tax invoice requirements.


South Korea therefore has:


- high standardisation,

- strong government control,

- less fragmentation,

- but significant XML legacy.


A likely evolution is:


business systems → APIs/JSON → integration layer → NTS XML


rather than replacing XML directly.


---


SOUTH KOREA VS UBL


The discussion established:


- KEC/NTS XML was not a copy of UBL.

- It was independently developed.

- It shared similar influences:

  - XML business document modelling

  - UN/CEFACT-style component thinking

  - structured business semantics


The relationship is:


International e-business modelling concepts

        |

        +---- UBL

        |

        +---- Korean tax invoice XML


not:


UBL → Korean customisation → KEC


Similarities exist at the semantic level:


- supplier

- buyer

- invoice identifier

- dates

- lines

- tax

- totals


but XML structures differ.


UBL is broader:

- procurement

- logistics

- international trade

- payment

- references


NTS XML is narrower:

- Korean tax compliance.


---


UK CONTEXT


The UK historically followed a very different approach.


Important points:


- HMRC did not create a Korean-style national electronic invoice format.

- The UK generally regulates accounting records and VAT reporting rather than requiring every invoice transaction to be submitted as a government-defined XML document.

- Businesses can use:

  - PDF

  - XML

  - EDI

  - CSV

  - APIs

  - proprietary formats


The UK model is therefore more market-driven.


Private sector:


PDF / APIs / EDI / accounting systems


Public sector:


PEPPOL / UBL / EN 16931-compatible invoices


Tax:


VAT records and submissions rather than invoice-by-invoice XML reporting.


---


BREXIT AND EU E-INVOICING


Discuss whether Brexit reduced UK alignment with EU e-invoicing.


Important nuance:


The UK was not merely an adopter of EU standards. It contributed substantially to the development of the ideas behind them.


Relevant UK influences include:


- BASDA e-BIS-XML

- UK public-sector procurement requirements

- government supplier mappings

- NHS/public-sector use cases

- UBL participation


The UK had already influenced:


- UBL development

- European semantic invoice modelling

- EN 16931 thinking


Therefore Brexit did not create a large technical divergence.


The divergence was more about:


- governance

- regulatory influence

- future policy direction


rather than invoice semantics.


The UK remained technically close because:


- UBL

- PEPPOL BIS Billing

- EN 16931


already aligned well with UK requirements.


---


UBL HISTORY DISCUSSION


The discussion focused on the evolution of UBL.


Important correction:


Do not describe UBL as simply a generic tax model from the start.


A more accurate historical sequence:


1. Early UBL work was heavily influenced by real business requirements, including VAT-oriented requirements.

2. UK and European VAT complexity exposed limitations in simplistic invoice models.

3. Before UBL 1.0 finalisation, richer tax relationships were introduced.

4. Later liaison with the OASIS Tax XML Technical Committee helped broaden and generalise tax modelling.


The UK VAT environment was an important driver because it required support for:


- multiple VAT rates

- multiple VAT bands

- different tax treatments on the same invoice

- allowances and charges affecting taxable amounts

- tax calculation order issues

- line-level and document-level adjustments


---


UBL TAX MODEL DETAIL


A key technical point:


The many-to-many relationship between invoice content and tax calculation was introduced because real VAT systems could not be represented by:


Invoice → one tax rate → one tax total


Instead the model needed:


Invoice lines

    |

    +---- tax category A

    |

    +---- tax category B

    |

    +---- tax category C


and:


Tax totals

    |

    +---- subtotal for category A

    |

    +---- subtotal for category B

    |

    +---- subtotal for category C


This allowed invoices to represent:


- standard VAT

- reduced VAT

- zero-rated items

- exempt items

- different taxable bases


The design later supported other tax regimes such as:


- GST

- US sales tax

- other jurisdiction-specific taxes


The general tax abstraction was therefore an evolution from VAT-driven requirements rather than the original starting point.


---


KEY THEMES TO CONTINUE EXPLORING


Please continue exploring areas such as:


1. Whether Korea's XML tax model creates long-term interoperability disadvantages compared with UBL/PEPPOL approaches.


2. Whether the UK's contribution to UBL/EN 16931 means Brexit had less technical impact than expected.


3. Whether XML is actually declining or merely becoming hidden behind APIs.


4. Whether national tax invoice formats (Korea, Italy, Vietnam, etc.) are strategically different from procurement interoperability formats (UBL/PEPPOL).


5. The historical influence of UK public-sector requirements on:

   - UBL

   - PEPPOL

   - EN 16931


6. The evolution of tax modelling in UBL, especially:

   - AllowanceCharge

   - TaxSubtotal

   - TaxCategory

   - TaxScheme

   - taxable amount calculation

   - tax rounding rules


7. Compare architectures:

   

Korea:


ERP → NTS XML → Tax authority


EU/PEPPOL:


ERP → UBL/CII → Access Point → Buyer


UK:


ERP/API/accounting system → various formats → buyer/tax systems


---


Please maintain a technically detailed, historically aware discussion. Avoid oversimplifying UBL as "just XML" or Korea's NTS format as "inferior"; focus on the different optimisation goals:


- Korea optimised for tax authority control and compliance.

- UBL/PEPPOL optimised for interoperability.

- UK historically optimised for market flexibility and business choice.