Connecting a group ERP to Vietnam's e-invoice system is mostly a data problem. The ERP passes invoice data to an e-invoice service provider, the provider formats and signs it, the tax authority codes it, and the buyer receives it. Almost every error a buyer or inspector later finds — a wrong tax code, an English-only description, a date one day off, a VAT rate that does not exist in Vietnam — was already present in the data the ERP sent.
So the work that matters happens before go-live and in the monthly routine afterwards: mapping ERP fields to what a Vietnamese invoice requires, deciding what the system should block, handling invoices the provider or the tax authority rejects, and having a written plan for outages. This guide is for group controllers, ERP owners and the Vietnamese finance lead who has to live with the result.
How the data travels
A typical flow for an invoice with a tax authority code:
- The ERP creates a billing document when goods are delivered or a service is completed.
- An interface sends the invoice data to the service provider.
- The provider builds the invoice in the prescribed electronic format, and it is signed with the company's digital signature.
- The data goes to the tax authority, which returns a code — or a rejection.
- The coded invoice is delivered to the buyer; the status flows back to the ERP.
The legal framework is Decree 123/2020/ND-CP as amended by Decree 70/2025/ND-CP, with guidance in Circular 78/2021/TT-BTC, and since 1 July 2026 also Decree 254/2026/ND-CP and Circular 91/2026/TT-BTC. We do not summarise the 2026 texts; format and field requirements are updated by the provider, so ask for written confirmation of what changed on their side and whether your interface needs to change with it.
Step 5 is where many integrations stop short. If the ERP never learns whether an invoice was coded or rejected, the finance team finds out from the customer.
Master data: the fields that decide whether an invoice is valid
| Data | What it must reflect | Typical ERP problem |
|---|---|---|
| Buyer legal name, address, tax code | The buyer's current tax registration | Customer created once from a trading name and never updated after a move or a change of name |
| Item descriptions | Vietnamese text, with any foreign language alongside | Global material master in English only |
| Units of measure | Units a Vietnamese reader understands | Internal codes such as "EA" or "CS" printed as they are |
| VAT rate or category | 0%, 5%, 10%, or a non-taxable or exempt category as the rules define | Group tax codes built for other countries' rates |
| Currency and exchange rate | Presented as the invoicing rules require | Rate taken from group treasury tables without a local rule |
Two practices save most of the trouble. First, keep a Vietnamese description field on the material and service master, maintained locally, rather than translating at print time. Second, verify every new customer's tax code on the tax authority's taxpayer lookup before the customer record is released for billing, and re-verify active customers periodically. The rates listed are those of Law 48/2024/QH15 on VAT; where a temporary reduction applies to certain goods under a resolution of the National Assembly, map it as a separate code with start and end dates so it switches off on time.
Dates, time zones and cut-off
Group ERPs often run on a server time zone that is not Vietnam's. An invoice created at 1 a.m. in Vietnam on the first day of a month may carry the previous month's date if the system uses a European time zone. That moves the sale into the wrong VAT period, and the buyer's period with it.
Set the invoice date on the Vietnamese entity from local time, and test it around midnight at month end. Check the same issue for delivery confirmations: if the invoice date is driven by proof of delivery, the time stamp on that proof must be in local time too.
Month-end is also where batch jobs cause trouble. A job that creates all service invoices on the last evening of the month may be convenient, but for services the invoicing moment is tied to completion of the service or earlier collection of payment. Map each billing type to the moment the rules set, then schedule the jobs around that, not the reverse.
Rejected, pending and cancelled invoices
Not every invoice sent is accepted. The provider may reject malformed data; the tax authority may refuse to code an invoice. Each case needs an owner and a clock:
- A queue of rejected invoices visible to the Vietnamese finance team, not only to the IT support desk, with the rejection reason in plain language.
- A daily check of pending invoices — sent but neither coded nor rejected — so that a stuck interface is noticed the same day.
- No re-use of ERP document numbers after a rejection without a record of what happened to the first attempt.
Cancellation deserves its own rule. Once an invoice is coded and sent, cancelling the ERP document does not cancel the invoice. Corrections go through adjustment or replacement as the rules provide, and the ERP should prevent a user from reversing a billed document without that step.
When the connection fails
Outages happen at the provider, at the tax authority or inside the group network. The invoicing rules contain provisions for situations where the system cannot be used; read them in the current text with your provider rather than improvising. What the company itself should have in writing:
- who decides that an outage exists, and who informs sales and logistics;
- whether goods may leave the warehouse during the outage and what documents travel with them;
- how invoices are issued and transmitted once the system is back, in what order, and who checks that none were missed;
- how the outage is recorded, with times, in case the tax authority asks later.
Manual invoicing deserves the same attention. In most FIEs a few invoices are always issued directly on the provider's portal — scrap sales, recharges to a tenant, a one-off service to a neighbouring factory. Each of these bypasses every ERP control. Keep a short list of who may issue invoices outside the ERP, for which kinds of transaction, and require them to be posted to the ledger within the same month with the invoice number as reference. Most unexplained differences in a year-end reconciliation trace back to invoices that were issued manually and booked late, or not at all.
Run the procedure once a year as a test. A plan nobody has tried usually fails on the simplest point: the person with the digital signature is on leave.
Controls and monthly reconciliation
Controls that fit most FIEs without adding headcount:
- Segregation of duties: the person who maintains customer master data is not the person who approves credit notes and adjustments.
- Block on missing Vietnamese descriptions or unverified tax codes at billing, not at month-end review.
- Change control on VAT codes: no new code or rate change in production without sign-off from the Vietnamese finance lead.
- Access logs on the provider portal and the signing service, reviewed quarterly.
Each month, reconcile three sources: invoices on the tax authority's e-invoice portal, sales in the ERP ledger, and the VAT return. Differences have a short list of causes — rejected invoices re-issued under new numbers, credit notes without adjustment invoices, time-zone shifts, manual invoices issued outside the ERP. A company doing this monthly spends an hour; one doing it at year end spends weeks and still cannot explain every line. Keep the invoice XML files and the reconciliation working papers for at least 10 years, the minimum retention for accounting documents under the Law on Accounting.
Where to check yourself
- The tax authority's e-invoice portal — the authoritative list of invoices issued and received, with status.
- The taxpayer information lookup — customer and supplier tax code status, names and addresses.
- The company's e-tax account — VAT returns and payments to reconcile against invoice data.
- The provider's admin console — interface logs, rejected and pending invoices, user access.
For the wider picture of how issuing, receiving and corrections work, see the other guides in our e-invoicing section.
Frequently asked questions
Can we keep product descriptions in English in the ERP?
Internally, yes. The invoice itself must carry Vietnamese descriptions, with English alongside if you want. Keep a local Vietnamese field on the master data rather than translating at print time.
Our ERP server runs on European time. Is that a problem?
It can be. Invoices created shortly after midnight in Vietnam may carry the previous day's date, which can move a sale into the wrong VAT period. Set invoice dates from local time and test around month end.
What should happen when the tax authority rejects an invoice?
It should land in a queue that the Vietnamese finance team sees, with the reason. Fix the data, re-send, and record what happened to the first attempt so numbers can be explained later.
Does reversing a billing document in the ERP cancel the e-invoice?
No. Once coded and sent, the invoice exists in the tax authority's system. Corrections go through adjustment or replacement as the rules provide, and the ERP should enforce that step.
Who should approve new VAT codes in the ERP?
The Vietnamese finance lead, through formal change control. VAT codes built for other countries are one of the most common sources of wrong rates on Vietnamese invoices.
How often should we reconcile the portal with the ledger?
Monthly. Portal invoices, ERP sales and the VAT return should agree each month; differences found quickly have a handful of obvious causes, differences found a year later rarely do.
