Turkish e-documents: direct integration or a special integrator?

An organization connecting e-Fatura, e-Arşiv, e-İrsaliye and e-Gider Pusulası — Türkiye’s electronic invoice, archive, waybill and expense-note documents — to its own systems has two routes: running the applications directly through its own information systems, or working through a licensed intermediary the regulation calls a special integrator. The question is usually discussed as one of technical capability. What actually separates the two is where responsibility sits.

This note compares the two along that axis: whose certificate applies the financial seal and the timestamp, who carries the archiving obligation, and whose team carries 7/24 operation and the work of tracking package versions. Everything below is cited as written in General Communiqué No. 509 on the Tax Procedure Law and in the technical guides published by the Turkish Revenue Administration.

The document family and the system each one connects to

The four documents do not connect through a single channel. Section V.8 of the communiqué draws the line directly: e-documents whose transmission is performed by the Administration, such as e-Fatura and e-İrsaliye, sit on one side, and documents outside that set, which reach the Administration’s system through an e-Document Report, sit on the other. The definitions section describes the e-Arşiv Fatura application as covering the creation, retention, presentation and reporting of the document — a reporting path, not a transmission one.

e-Gider Pusulası does not open a channel of its own. Section IV.6.2 requires an organization joining that application to have joined the e-Fatura application first, and IV.6.1 states that the document is not a new document type but carries the same legal qualities as the paper expense note. It rides on the existing line.

Section V.1 defines three ways to use the applications: the Administration’s own portal, a special integrator, and direct integration. The portal is scoped to a certain size of use and falls outside this note; the comparison here is between the latter two. Every section that follows tracks a single question — which obligation stays with whom.

Direct integration: application conditions and the operations you take on

Section V.1.3 sets the threshold: organizations whose information systems are sufficient may use the e-document applications directly through their own systems, provided they establish the necessary integration. Applicants who are approved receive test user and authorization definitions by e-mail, and integration work must be completed within one year of the application date at the latest. That is not a target — it is the ceiling the communiqué gives.

The steps are ordered in the Integration Guide: after the application, an Information Systems Report and a Test Definition Form are completed, with the form declaring the server and client IP addresses and the web service endpoints that will connect to the test environment. Test accounts are defined by the Administration and sent by e-mail, testing follows the e-Fatura Test Plan, and once the steps are completed the test accounts are closed and a Live Definition Form is filled in.

The network conditions are written down as well. Section 4.2 of the guide states that integrating units will be defined to the application through their static IPs, and that the static IP will be within the IP range belonging to Türkiye. Group companies wanting to connect over a shared IP have their requests assessed by the Administration on application, with documents showing the ownership ties.

The real weight begins after that. The organization operates the sender unit and mailbox roles itself. Sections 3.1 and 3.2 of the guide require the system to be running at all times — 7x24 — so that outgoing and incoming messages can be tracked, and require the unit to ensure business continuity as well. The same sections make logging mandatory at every step.

A single sentence in the guide’s footnote is decisive: the centre does not perform signature verification, and signature verification must be performed by the sender unit. The same wording appears for the mailbox. This is the clearest indication of where the operational weight falls.

The special integrator model: operations handed over, boundary set by contract

The communiqué defines a special integrator as an integration organization that has the technical competence to serve taxpayers in creating, signing and transmitting electronic documents, and that can obtain permission from the Administration at the end of testing and assessment. Section V.1.2 lists the scope of service: creating e-documents and e-document reports, approving them with a financial seal, using a timestamp, and transmitting the documents to the recipient and the reports to the Administration electronically.

What the integrator takes on is spelled out in the Special Integration Guide. Information security calls for TS ISO IEC 27001 obtained from bodies accredited by TÜRKAK, business continuity for ISO 22301, and IT service management for TS ISO IEC 20000. System management processes must be ITIL-aligned and the system managed by ITIL-certified personnel. A Financial Seal Compliance Assessment Report is obtained from the TÜBİTAK-BİLGEM Public Certification Centre. The system must be built to sustain 7/24 business continuity in electronic invoice traffic, and that approach must be described in the Information Systems Report with annual average invoice and user counts, concurrent capacity and load test data.

Where the boundary is drawn matters. The regulation does not define the shape of the interface a special integrator offers its own customers; what it defines is that the connection model between the integrator and the Administration is a web service. The customer-facing interface is a matter of contract and technical documentation. Section 2.2 of the guide ties this down in one sentence: the operations that can be performed with the user account shall be stated explicitly in the contract with the special integrator and undertaken there. That is the only place the boundary of responsibility is drawn in writing.

The switching rules are defined too. The application can be used through more than one special integrator; but those sending and receiving invoices through an integrator cannot use the portal and the direct integration method at the same time. An organization that previously held an integration permission must inform the Administration in writing and request closure of its integration account when moving to an integrator. The special integration test process is completed within one year of the start of the work.

Financial seal, timestamp and the retention obligation

Section V.9 defines the financial seal as the electronic certificate infrastructure prepared by TÜBİTAK-UEKAE on behalf of the Administration, created to guarantee data integrity, source and content and, where necessary, confidentiality. The qualified electronic certificate is the one defined in Article 9 of Electronic Signature Law No. 5070, usable only by real-person taxpayers.

The default rule sits in the same section: it is the norm for taxpayers to approve their e-documents with their own financial seal certificates or sign them with their qualified electronic certificates. For those using the applications through special integrators, the Administration may permit the documents to be approved with the integrator’s financial seal certificate. The handover is not automatic: section V.1.2 states that taxpayers receiving service through an integrator’s system may request that the integrator’s financial seal and timestamp be used.

A timestamp is defined as the record, verified by an electronic certificate service provider, establishing the time at which electronic data was produced, changed, sent, received or saved. Where it is required is written down as well: the e-document report is signed with an electronic certificate and a timestamp before being transferred to the Administration’s system, and e-Arşiv reports are signed using the XAdES-A standard with a financial seal or electronic signature plus a timestamp. Since 1 January 2019, e-Arşiv reports are sent in daily periods, by the end of the following day at the latest.

The load-bearing sentence of this section is repeated in three separate places. V.1.2: performing the sending and receiving of e-documents through the information system of a permitted special integrator does not remove the taxpayer’s retention and presentation obligations. V.8: meeting the access and reporting requirements does not remove those obligations either. VI: obtaining electronic archiving service from other taxpayers, including storage organizations permitted by the Administration, does not remove the taxpayer’s primary responsibility for retention and presentation. Whichever route is chosen, that obligation stays put.

The data locality condition is written in two places. V.1.2 requires the software and hardware infrastructure used in sending and receiving e-documents to be located within the borders of the Republic of Türkiye and in places where its laws apply. Section VI repeats the same condition for retention and leaves one opening: the requirement does not prevent a secondary archive being kept abroad. The scope of retention is not narrow either — every kind of electronic record and data relating to the accuracy, integrity and immutability of the archived documents, along with database files, the storage medium, and the verification and display tools. The same section notes that because the validity of an electronic signature and a financial seal can only be checked electronically, printing an e-document to paper for retention by its issuer is not applicable.

Tracking package updates and their effective dates

On the e-document side, the guides and packages do not stand still; the stream of announcements carries its own cadence. The gap between the announcement date and the date an update goes live is not fixed either — each announcement declares its own.

• Announcement of 9 December 2025: the investment incentive technical guide, the e-Fatura package, the e-Arşiv Fatura package, the UBL-TR code lists guide and the UBL-TR 1.2.1 package were updated; the updates went live on 22 December 2025.
• Announcement of 9 January 2026: the deadline for developments in the İDİS technical guide was extended to 2 February 2026 and the same four artefacts were updated again; live on 2 February 2026.
• Announcement of 16 March 2026: registry and activity code checks for documents issued through special integrator systems began on 1 April 2026; live on 1 April 2026.
• Announcement of 27 July 2026: the e-Fatura package, the e-Arşiv Fatura package and the UBL-TR code lists guide were updated; the updates go live on 14 September 2026.

Two observations follow. First, there is no single file to watch: the e-Fatura package, the e-Arşiv Fatura package, the code lists guide and the UBL-TR package are usually named together in the same announcement. Second, the calendar can shift — on 27 March 2026 the postponement of the VAT rate check tied to registry and activity codes was announced separately. Guide versions move on the same stream: on 22 May 2026 the e-Arşiv application guide and the e-Müstahsil Makbuzu technical guide were updated and the e-Gider Pusulası package was published, and on 29 June 2026 the Special Integration Guide reached v1.14.

Responsibility divides like this: under direct integration, following that stream and applying it to your own line is your team’s work. Under the integrator model, the integrator’s system carries the updates — but the fields that have a counterpart in your ERP stay in your own development queue.

How code list changes land in ERP field mapping

A code list update has a concrete counterpart on the ERP side. The 16 March 2026 announcement added a new code for cases such as pass-through invoices and fixed-asset sale invoices, where an invoice cannot be issued at the VAT rate corresponding to the activity code.

555 — Sales Not Subject to VAT Rate Check

Where that code is not mapped to a sales type in the ERP, the document cannot pass the corresponding check. A second example comes from the 12 January 2026 announcement: invoices issued under the YATIRIMTESVIK scenario with the ISTISNA invoice type, and on the e-Arşiv side under the EARSIVFATURA scenario with the YTBISTISNA type, carry a Waived VAT Amount. The announcement defines the field’s behaviour as well: it is shown only in the XML, it is not included in line or grand totals, and it does not appear on the invoice rendering — and the XSLT files for that scenario and invoice type need updating.

Why the XSLT is the ERP’s work is written in section 4.3 of the Integration Guide: an XSLT definition to be used for display must be present inside the XML files, and where the XSLT and the invoice XML differ in content, the information in the XML prevails. The same section defines the data side too — the format is XML, correctness is checked against XSD schemas, character encoding is UTF-8, signing uses at least the XAdES-BES standard with the enveloped technique, and the signed XML is compressed with ZIP as the envelope is formed.

Code lists are reference datasets that grow over time. The version table of the code lists guide shows it: version 1.6 (5 August 2015) added the IHRACKAYITLI invoice type and its code list, version 1.7 (25 August 2015) added the excise duty exemption code list, and the guide now stands at 1.27. The practical consequence: where a code list is embedded as literal text in the ERP, every update calls for hands-on work; where it is held as a separate mapping table, an update becomes a data task. That distinction stays on your side under either method.

Keeping the document lifecycle traceable inside the ERP

The lifecycle does not end when the document is sent. The application response and the e-İrsaliye response are separate events, and where they are not attached to the document in the ERP the status picture stays incomplete. The windows are defined in the guide: the sender unit should not accept application responses arriving more than eight days after the invoice was sent, and where more than one response arrives for an invoice the first should be accepted. The mailbox should send its application response within eight days of receiving the invoice. On the waybill side the same pattern runs on seven days, and sending a waybill response is optional.

The business counterpart sits in section IV.3.4. The recipient can declare partial acceptance through the e-İrsaliye response; anything outside acceptance has to be declared before the goods are physically dispatched. Responses of that kind sent after physical dispatch produce no effect, and a new e-İrsaliye is issued instead. That requires the ERP to hold shipment status and document status in the same place. The same section makes retention relational as well: organizations permitted into the application must retain and present their e-İrsaliye documents and e-İrsaliye responses in relation to one another.

The notification path connects to the system too. Section V.10, added by Communiqué No. 526, requires that notifications made under the third paragraph of Article 18 of the Turkish Commercial Code — through a notary, registered mail, telegram, or registered electronic mail with a secure electronic signature — together with e-document cancellation transactions, be reported electronically to the Administration’s information system from 1 May 2021 onwards.

There is a written obligation for out-of-course situations as well: where electronic records cannot be processed, the situation must be reported to the Administration within three business days along with a detailed plan for how those records will be completed. Section VIII adds one more clause for organizations using the applications through their own systems: the software, hardware, files and documentation making up the information system cannot be made subject to a contract or licence that would obstruct access by inspection staff. That is the clause to read when a software supply contract is being drafted.

Reducing the decision to three axes

The choice between the two methods gathers into three axes, and each of them attaches to a verifiable clause.

• Team capacity: under direct integration, keeping the system running 7x24, logging at every step and performing signature verification on your own side all sit with your team. The ceiling the communiqué gives for integration work is one year.
• Audit expectation: on the integrator side an information systems audit is defined and periodic — carried out every two years following the first audit date, with independent audit reports valid for at most two years from their date, the opinion letter and report annex sent to the Administration within fifteen days at the latest, and audit service taken from the same auditor at most twice consecutively. Under direct integration, the Administration may request further information and may carry out, or have carried out, an on-site examination of the information system.
• Document volume and mixed use: service can be taken from more than one special integrator, but those sending and receiving through an integrator cannot use the portal and direct integration at the same time. The choice of method is reversible, but singular at any one moment.

Three things stay the same on either route: the primary responsibility for retention and presentation stays with the organization, the requirement that infrastructure and retention sit within Türkiye’s borders holds, and the financial seal does not transfer on its own — it is requested, and written into the contract.

Four questions remain at the close. Which document connects to which channel? Whose certificate applies the seal and the timestamp? In what medium and within which borders does retention happen? Who tracks package and code list updates, and who applies them? Where those four can be answered in writing, the choice of method follows on its own.

This note cites regulation and guide texts as written; it does not constitute legal advice. Because guide versions and effective dates change, check the current announcements and guide versions on ebelge.gib.gov.tr before planning.

Sources

• General Communiqué No. 509 on the Tax Procedure Law, current version — Turkish Revenue Administration (methods of use V.1, special integrator V.1.2, direct integration V.1.3-V.1.4, financial seal V.9, retention and presentation VI)
• General Communiqué No. 526 on the Tax Procedure Law — Official Gazette, 9 February 2021, no. 31390 (section V.10 added to 509: electronic reporting of notifications and cancellations)
• e-Fatura Application Integration Guide, Version 1.10, June 2018 — Turkish Revenue Administration (information systems report and test process, static IP condition, 7x24 operation and logging, signature verification, XSLT and XML rules, application response windows)
• e-Fatura Application Special Integration Guide, Version 1.14, June 2026 — Turkish Revenue Administration (certification and ITIL conditions, financial seal compliance report, business continuity, contractual undertaking, switching rules)
• e-Document Special Integrators Information Systems Audit Guide, Version 1.0, November 2019 — Turkish Revenue Administration (audit period, report validity, fifteen-day submission window, auditor rotation)
• e-Arşiv Application Guide, Version 1.18, August 2025 — Turkish Revenue Administration (signing reports with XAdES-A, daily reporting period)
• UBL-TR Code Lists Guide, Version 1.27 — Turkish Revenue Administration (version table and code lists added over time)
• Turkish Revenue Administration e-Document announcements — ebelge.gib.gov.tr (announcements dated 9 Dec 2025, 9 and 12 Jan 2026, 16 and 27 Mar 2026, 22 May 2026, 29 Jun 2026 and 27 Jul 2026)