Türkiye's E-Document Packages Updated: What to Do on the ERP Side

Update (5 October 2026): the 14 September 2026 go-live date stated in the announcement from GİB (the Turkish Revenue Administration) has passed. We found no announcement on the e-document portal postponing it; for current package versions and later announcements, ebelge.gib.gov.tr is the authoritative source. The checklist below applies to future package updates as well.

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 announcement published on 27 July 2026 on the e-document portal of the Turkish Revenue Administration (GİB), the e-Invoice, e-Archive and UBL-TR (code list) packages were updated, and the announcement stated that the updates would go live on 14 September 2026. In August, the e-Archive (11 August 2026) and e-Invoice (24 August 2026) packages were revised again 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 e-document process runs through the API of the private integrator you have contracted (or, if you hold direct integration approval from GİB, through that route).

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:

1. 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.
2. 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.
3. 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.
4. 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.
5. 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.
6. 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.

In integrations of this kind, a large share of common disruptions stems from items three and four. 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

Common mistakes in systems of this kind come from assumptions rather than technical difficulty:

1. 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.
2. One-way integration. Outbound automated, inbound manual. This quietly delays supplier reconciliation and cost recording.
3. 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.
4. Keeping the archive entirely outside. Access to history becomes a problem when a contract ends or a provider changes.
5. 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

This update's go-live date was 14 September 2026, and e-document packages continue to be updated at regular intervals. On 25 September 2026, for example, GİB announced an update to the e-Currency and Precious Metals Purchase and Sale Document package, going live on 2 November 2026. For a prepared company, a date like this 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:

• ERP Software Development
• API and Integration Solutions
• Factory Software Solutions
• Custom ERP Software for Gaziantep Factories

Sources (last checked: 5 October 2026)

• GİB (Turkish Revenue Administration) e-document portal, announcements: ebelge.gib.gov.tr/duyurular.html (27 July 2026 e-Invoice, e-Archive and UBL-TR package announcement; 11 August 2026 and 24 August 2026 correction announcements; 25 September 2026 e-Currency and Precious Metals Purchase and Sale Document package announcement)

This article is not tax advice; for questions on obligations, thresholds and scope, consult your financial adviser.