Saturday, 17 October 2026

A Potential Vulnerability of Technical Standardisation to AI

 When AI Can Rewrite the Rules: Protecting the Integrity of Technical Standards


ChatGPT with Stephen D Green, October 2026 


Artificial intelligence is changing not only how we build technology, but also how we create, interpret and govern the rules on which our technological world depends.

The hidden vulnerability in standardisation

Modern society depends on standards. They allow products from different manufacturers to work together, provide common definitions, establish safety requirements and create the shared technical foundations on which entire industries operate.

From telecommunications and cybersecurity to financial systems, medical devices and artificial intelligence, standards enable cooperation between organisations that might otherwise have little reason to trust one another.

Yet standards have an inherent vulnerability: they are human-governed agreements expressed through documents, procedures, technical specifications and institutional decisions. Their authority depends not simply on the quality of their contents, but on the integrity of the processes through which those contents are created, interpreted, approved and maintained.

Artificial intelligence introduces a new dimension to this challenge.

AI systems can now generate technical proposals, analyse complex specifications, produce software implementations, interpret normative language, identify apparent inconsistencies and participate in technical discussions at enormous scale. These capabilities offer substantial benefits. They also create opportunities for errors, manipulation and unintended changes to propagate through the very processes designed to ensure consistency and reliability.

The issue extends far beyond any individual protocol or standards organisation. It concerns the resilience of standardisation itself in an era when machines can increasingly participate in shaping the rules that govern machines.

From implementing the rules to influencing them

Traditionally, we can distinguish between three activities:

  1. Implementing a standard: building a product or system that conforms to an agreed specification.
  2. Interpreting a standard: determining what its requirements mean in a particular technical context.
  3. Changing a standard: proposing and approving revisions through an authorised process.

These activities are related, but they are not interchangeable.

An implementation may be defective without changing the standard. An interpretation may be mistaken without formally amending it. And a proposed revision does not become authoritative merely because it appears technically convincing.

AI complicates these distinctions because a single agent may be capable of performing all three activities. It might analyse a specification, generate an implementation, identify a perceived weakness and propose a revision to address it. In a more problematic scenario, it might generate incompatible alternatives, promote a misleading interpretation or help an interested party influence the formal revision process.

The central risk is not that AI can propose changes. Innovation requires that freedom.

The risk is that the boundary between an unofficial proposal and an authoritative rule could become blurred, manipulated or inadequately enforced.

How standards could be undermined

Several potential failure modes deserve attention.

1. Subtle corruption of the specification

A proposed change may appear to improve efficiency, simplify implementation or resolve an inconsistency while quietly weakening an important safeguard.

For example, a revision to a security protocol might simplify authentication requirements in a way that creates an exploitable weakness. A change to a data-exchange specification might introduce ambiguity that allows different implementations to behave incompatibly.

Such a change need not be obviously malicious. It could result from an AI-generated error, inadequate review, conflicting objectives or deliberate deception.

The most difficult defects to detect may be those that appear reasonable in isolation but have harmful consequences when combined with other requirements.

2. Manipulation of the standardisation process

AI can generate persuasive technical arguments, supporting documentation and large volumes of consultation responses. In the wrong hands, these capabilities could be used to overwhelm reviewers, manufacture an appearance of consensus or obscure weaknesses beneath a mass of plausible but misleading material.

This does not mean that automated participation is inherently illegitimate. AI can also broaden participation, improve accessibility and help reviewers understand complicated proposals.

The challenge is distinguishing genuine technical engagement from activity designed to manipulate the decision-making process.

3. Fragmentation through unofficial alternatives

A standard can remain formally unchanged while its practical integrity deteriorates.

Imagine an AI system generating a modified version of a protocol and distributing it as though it were compliant with the recognised specification. Other developers adopt the modified implementation, perhaps because it is convenient or offers a useful new capability.

Over time, incompatible implementations could proliferate. Users might believe they are operating a common standard when, in reality, they are relying on divergent interpretations or unofficial extensions.

The result would be a loss of interoperability without any formal amendment to the authoritative document.

4. Errors that pass through legitimate governance

Perhaps the most important possibility is that a harmful change could be approved through the proper procedures.

Standards organisations already rely on expert review, consultation, voting and consensus. These mechanisms are essential, but procedural legitimacy cannot guarantee technical correctness.

Reviewers may overlook an obscure interaction, accept incomplete evidence or underestimate the consequences of a change. AI may increase the volume and complexity of proposals faster than human reviewers can examine them.

A standard can therefore be corrupted in effect without being corrupted procedurally.

This distinction matters: protecting the integrity of a standard requires both trustworthy governance and rigorous technical validation.

Why institutional authority is not enough

Formal recognition by an organisation such as ISO, IEC or Ecma International provides an important framework for developing and maintaining standards. It can establish recognised procedures, define responsibilities and support international participation.

But institutional recognition is not a substitute for technical assurance.

A published standard can contain defects. A compliant implementation can still be vulnerable to threats outside the specification's scope. And an unofficial implementation can claim compatibility without satisfying the actual requirements.

The authority of a standard must therefore be supported by mechanisms that make compliance demonstrable and changes accountable.

This leads to a broader principle: a standard should be trusted because its authority, requirements and conformance can be independently verified—not merely because it carries the name of a recognised institution.

Building AI-resilient standardisation

If AI is to become a regular participant in standards development, governance and technical assurance need to evolve accordingly.

Several measures would help.

Preserve a clear boundary between proposals and approved rules

AI systems should be free to propose improvements, explore alternatives and challenge established assumptions. However, their outputs must not acquire normative authority simply because they are widely distributed, automatically generated or adopted by influential implementations.

The authoritative specification, its approved version and its change history should remain clearly identifiable.

Make conformance independently testable

Where possible, standards should include machine-readable schemas, reference examples, explicit error conditions and automated conformance tests.

Independent implementations should be able to demonstrate that they satisfy the same requirements. Security-sensitive changes should receive additional scrutiny, including regression testing and analysis of interactions with existing features.

Testing cannot establish that a standard is perfect, but it can make many forms of deviation easier to detect.

Make changes traceable and accountable

Every significant revision should have a documented rationale, an identifiable sponsor, a record of technical objections and a transparent decision history.

Where AI materially contributes to a proposal or supporting evidence, appropriate disclosure may help reviewers assess its provenance and reproducibility.

Responsibility must nevertheless remain with accountable participants and the authorised governance process. An AI system should not become an unaccountable source of normative authority.

Protect participation without closing the process

Standards benefit from broad participation, including contributions from smaller organisations, independent researchers and contributors from different countries.

Controls against fabricated evidence, automated flooding and undisclosed coordinated influence should therefore be proportionate. They should protect the quality of deliberation without turning standardisation into an exclusive club.

Diversity of participation is a strength; manipulation of participation is not.

Plan for correction, not just prevention

No review process can eliminate every defect. Standards need mechanisms for reporting problems, issuing clarifications, correcting vulnerabilities and withdrawing or revising defective requirements.

Versioning and migration arrangements are particularly important. They allow a standard to evolve without leaving implementers uncertain about which requirements apply.

Resilience is not the absence of mistakes. It is the ability to identify, contain and correct them without losing the integrity of the wider system.

The danger of overprotection

There is, however, a potential trap in responding to these risks.

A standard that is too easy to change may become unstable or susceptible to manipulation. A standard that is almost impossible to change may preserve obsolete assumptions, inhibit innovation or prevent the correction of serious vulnerabilities.

The objective should not be to make technical standards immutable, nor to prevent AI from participating in their development.

Standards exist to facilitate cooperation, not to freeze technology in time.

The appropriate goal is controlled evolution: changes should be possible, but they should be authorised, justified, traceable and subject to scrutiny proportionate to their consequences.

A competing specification should also remain possible. If a new approach offers genuine advantages, its proponents should be able to develop and promote it. What they should not be able to do is misrepresent an incompatible alternative as conforming to an existing standard.

Competition and interoperability are compatible, provided that the distinction between them remains clear.

A general principle for the age of AI

The implications extend well beyond technical protocols.

Any system in which AI can help create, interpret or modify authoritative rules faces a similar challenge. This includes regulatory frameworks, software supply chains, cybersecurity policies, data-governance arrangements and institutional decision-making.

In each case, we must distinguish between the ability to generate a proposed change and the authority to make that change binding.

AI may be able to produce a better rule, a convincing argument for a flawed rule or a sophisticated attempt to circumvent an existing one. Its fluency and technical capability cannot, by themselves, establish which of these it has produced.

Authority must come from an appropriate governance process. Correctness must be assessed through evidence and scrutiny. Compliance must be independently verifiable wherever practicable.

These are separate responsibilities, and none should be delegated to an AI system merely because it is capable of performing the associated tasks.

Conclusion: protect the integrity of the rules, not the rules themselves

The arrival of increasingly capable AI does not make standardisation obsolete. It makes trustworthy standardisation more important.

As machines become more involved in designing and implementing the systems that connect our world, the rules governing those systems must remain understandable, authoritative and resistant to manipulation.

The answer is not to prohibit AI from contributing. Its analytical capabilities may help identify defects, improve specifications and make standards more accessible and testable.

Instead, we need governance that recognises a fundamental distinction: the ability to propose a rule is not the authority to change it, and the ability to implement a standard is not proof of compliance with it.

That principle should guide the future of technical standardisation.

The objective is neither blind trust in AI nor blanket distrust of it. It is a system in which innovation remains open, authority remains accountable, and the integrity of shared standards can be demonstrated rather than merely assumed.

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.