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:
- 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.
