Under e-invoicing, an invoice is only accepted if it carries the right data in the right fields. This is a real shift: today a missing detail on an invoice is a nuisance a person works around; under structured e-invoicing it can cause the invoice to be rejected in the flow, stopping the transaction. Knowing what data an e-invoice must carry, and making sure your systems hold it, is therefore central to readiness. Here is what those fields are and why they matter.
The invoice as a set of fields
Where a paper invoice is a layout, an e-invoice is a defined set of data elements. Each element, the parties, the amounts, the tax, the goods, has its own field, and the standard specifies which are required. The exact list is defined by the framework, but the categories are predictable and map closely to what a proper tax invoice already contains, now expressed as structured data rather than text on a page.
| Field group | What it holds |
|---|---|
| Parties | Supplier and buyer identity and tax numbers |
| Invoice references | Unique number, dates, and type |
| Line items | Description, quantity, unit price per line |
| Tax details | Rate, VAT amount, and category per line |
| Totals | Net, tax, and gross amounts |
| Payment details | Terms and, where relevant, references |
Why completeness is now enforced
The critical change is that these fields are validated automatically. A missing tax number, an absent line-item detail, or a total that does not reconcile is not overlooked; it can be flagged and the invoice rejected before it reaches the buyer or the authority. Compliance moves from something checked occasionally, after the fact, to something enforced at the moment of exchange. That is a higher bar, and it is unforgiving of the small gaps that manual processes tolerated.
Every required field must be present and correct, because the system checks each one as the invoice is exchanged. A gap a person would have ignored can now stop the invoice, and the transaction with it.
Where the data has to come from
An invoice can only carry correct data if that data exists in your systems. The buyer's tax number has to be in your customer record; the product details and tax categories have to be in your item master; the totals have to reconcile from your pricing. This is why data cleanliness is the real preparation task: the e-invoice is only as complete as the records feeding it, and gaps in those records become gaps in the invoice, which become rejections.
What to do about it
Map the required fields against what your systems actually hold, and find the gaps before they cause rejections. Make sure customer records carry tax numbers and correct addresses, that products and services carry the right tax categories, and that your invoicing reconciles cleanly. Treat the field list as a data checklist for your master records, not just a technical specification. When the data behind the invoice is complete and correct, the e-invoice largely takes care of itself; when it is not, every gap surfaces at the worst possible moment.
This article is general information and is not technical advice. The required data elements are defined by the Ministry of Finance and continue to develop. We would be glad to help you map your data to the standard.