Türkiye's E-Document Packages Updated: What to Do on the ERP Side
Türkiye's e-Invoice, e-Archive and UBL-TR package updates go live on 14 September 2026.
The finance manager at a factory receives a short email from the e-invoicing integrator: "New package published, it goes live on 14 September." The sentence is technical, its addressee is unclear, and in most companies it ends up in the same place: an unread thread in the inbox. Then one day an invoice the system had issued without trouble for years is rejected, and the problem reaches as far as a held shipment.
According to the announcements published on the Turkish Revenue Administration's e-document portal, the e-Invoice, e-Archive and UBL-TR packages were updated during the summer of 2026, and the announcement states that the updates will go live on 14.09.2026. Following the packages published at the end of July, both the e-Archive and e-Invoice packages were revised again in August to correct gaps.
This article explains what such an update means on the ERP and integration side, where the phrase "the integrator handles it" is true and where it is misleading, and which checks your company has to run on its own side. Always treat the announcements on ebelge.gib.gov.tr as authoritative for current package versions and dates; the dates here reflect the announcements as of publication.
What Is a "Package", Exactly?
E-document packages contain the schema files (XSD) that define the XML structure of documents, the code lists, and the implementation guides. Every invoice you issue is validated against that schema. When the schema changes, the format of the document you send has to match the new definition.
Changes usually land in three places:
- The schema (XSD). New fields appear; the mandatory status or format of some fields changes.
- The code lists. Unit codes, tax codes, country codes, scenario and type definitions gain additions and corrections.
- The guide. Explanations of how fields should be populated are clarified. This is usually the least-read part and the one that causes the most trouble.
For most companies an update breaks nothing. Where it does cause problems, the cause is almost always the same: fields filled in a non-standard way. A unit code left as it is because "it has always worked", or information squeezed into a description field, gets rejected the moment the rules tighten.
Where "The Integrator Handles It" Stops Being True
The e-document flow passes through three layers, and responsibility differs at each.
| Layer | What it does | Where responsibility sits |
|---|---|---|
| ERP or accounting software | Produces the content of the document: line items, codes, amounts, scenario | With you |
| Integrator or private integrator | Transports the document, validates it against the schema, handles communication with the administration | With the service provider |
| Revenue administration | Defines the rules and schema, accepts or rejects the document | With the institution |
Your integrator updates the transport and validation layer, and that part genuinely is their job. But you produce the content of the document. When the schema makes a new field mandatory, or a code list changes, your ERP has to produce the data that fills it. An integrator cannot invent data that does not exist.
The distinction matters most in custom-built ERPs and in packaged software left on an old version. Because ERP mappings are typically configured once and then forgotten, the change is usually noticed through the first rejected document.
A Pre-Go-Live Checklist
When an update is announced, these are checks a technical team can complete in a day:
- Run a pass in the test environment. Push your three most complicated real-world documents against the new package: an export invoice, a multi-line sale with discounts, and a return or a document with withholding. Your routine invoice will pass; the risk lives in the exceptions.
- Review the code list mappings. Unit codes, tax and exemption codes, country codes. Someone has to know where these mappings live in the ERP, and that knowledge must be reachable when that person is on leave.
- Make the rejected-document queue visible. If rejected documents accumulate silently in a table, the problem surfaces only when a customer calls. Rejections need a screen, and an owner.
- Do not forget the inbound side. Most integrations are built around outbound invoices, while inbound e-invoices and dispatch notes are left to manual entry for years. An update is a good occasion to review that gap.
- Archive and retention. Make sure your documents remain accessible for the full statutory retention period. Keeping the entire archive only at the integrator creates a problem when the contract ends.
- Someone who follows release notes. A person who watches the announcements page, and an internal channel where that information lands. This is a matter of organisation, not software.
Items three and four account for most of the disruptions we see. Neither is technically difficult; they are simply the areas nobody owns.
Why the Test Environment Gets Skipped
The answer is usually this: setting up a test environment takes effort the first time, and that effort is postponed because "it does not contribute to production". Yet on the e-document side, a test environment is insurance that pays out several times a year. Preparing a set of sample documents once and keeping it turns every package update into a half-hour job.
It is one of the most concrete examples of test and QA automation: running an unchanging set of checks against a changing external rule, over and over.
Five Common Mistakes
The mistakes we see repeatedly come from assumptions rather than technical difficulty:
- Assuming "the accounting software already does it". The software may be sending the document. Who produces its content, and what happens when it is rejected, are separate questions.
- One-way integration. Outbound automated, inbound manual. This quietly delays supplier reconciliation and cost recording.
- Using the description field as a data store. Information that does not fit the structure ends up in free text, and on the day the rules tighten the document is rejected, or worse, nobody can report on the data.
- Keeping the archive entirely outside. Access to history becomes a problem when a contract ends or a provider changes.
- Version tracking tied to one person. When the person who watches the announcements leaves, the process leaves with them.
The Wider Picture: E-Transformation Points One Way
Taken alone, package updates are a technical detail. Taken together, they show a direction: the space for paper documents is narrowing, scope is widening, and consistency checks between documents are increasing. E-invoice, e-archive, e-dispatch and e-ledger are becoming different faces of the same data.
The consequence for ERP is this: you need a structure that derives documents from a single data model, rather than producing each one separately. In systems where the dispatch note and the invoice are fed from different places, inconsistency is inevitable, and the audit side can now see those inconsistencies.
Which threshold applies to you, and when you must move to which document type, is a tax question and should be settled with your accountant. Because thresholds and scope change over time, we point to the source rather than printing figures here: current communiqués and announcements govern.
The Extra Risk in Systems Tied to One Person
In many factories running custom software, the e-document integration was written years ago by a single developer and nobody has touched it since. As long as the system works, this does not look like a problem. It becomes one on the day an external rule changes: if that person is unreachable, if you do not hold the source code, or if no document explains how the code works, a half-day task stretches into weeks.
There is a simple way to measure the risk. Ask where the integration code lives, who can access it, and who changed it in the last year. If the answers are vague, the package update is not your real problem. Taking over such systems and making them maintainable is what we cover under software takeover.
Where We Draw the Line
Tax interpretation, threshold assessment and liability decisions are not our work; they belong to your accountant. Integrator selection is a commercial decision as much as a technical one, and we prefer to stay neutral on it.
What we do is build the layer between the ERP and the integrator properly: correct data production, manageable mappings, visible errors, and inbound documents that actually land in the system. It is conventional API and integration work, and once it is built well it pays back at every package update.
Conclusion
For a prepared company, a go-live date such as 14 September 2026 is an ordinary marked day. For an unprepared one it is a week of rejected documents, phone calls and waiting shipments. What separates the two is not new software: a test environment, owned mappings, a visible error queue, and someone who follows the announcements.
To review your e-document flow end to end and see the gaps on the ERP side, get in touch. The review usually starts with your three most complicated documents, because that is where the system's real limits show.
Related reading: