Türkiye's e-Document System: Clearance, Integrators and SAP S/4HANA
How invoices are cleared through the Revenue Administration (GİB), what a private integrator such as Sovos and EDI channels actually do, and what it takes to connect SAP S/4HANA — including the certificates.
Client dossier · September 2026 · CFOs, Finance, IT, PMs
Download Full Briefing (PDF)4 documents
e-Fatura, e-Arşiv, e-İrsaliye and e-Defter — each with its own rules and timing
Clearance
Invoices pass through GİB before reaching the customer, in near real time
Mali Mühür
A financial seal certificate is required to sign every document
10 years
Retention under commercial law — archiving abroad is not permitted
Key takeaway for finance and IT leaders: in Türkiye the compliance risk is rarely the invoice content — it is availability. An expired certificate, a firewall change or a missing trust entry stops billing and, with e-İrsaliye, stops shipping. Certificate ownership, monitoring and renewal belong in the design from day one, not in a handover document.
A Clearance Model, Not a Reporting Model
France asks you to route invoices through approved platforms. Spain will ask for a copy. Türkiye goes further: for registered taxpayers, the invoice only exists once it has passed through GİB. The document is created in UBL-TR format, signed with a financial seal, transmitted, validated and then delivered to the buyer's mailbox inside the system.
Scope has widened every year: thresholds have been lowered repeatedly and sector rules added. As a working assumption, a general turnover threshold in the low millions of lira brings a company into e-Fatura, with far lower thresholds for e-commerce, accommodation and real estate — and from 1 January 2026 the low-value exemption for e-Arşiv was removed, so effectively every invoice is electronic.
The Four Obligations at a Glance
Sales to counterparties registered in the system (B2B and B2G). Cleared at issuance, before delivery to the buyer.
Sales to everyone else: consumers, unregistered businesses, foreign customers. Delivered to the customer directly; reported to GİB by the following day.
Physical movement of goods. Approved before the goods leave the premises.
Journal and general ledger in electronic form. Created periodically, with a signed summary (berat) uploaded to GİB.
Related documents follow the same logic for specific cases — self-employment receipts, producer receipts, e-tickets and e-receipts. Thresholds, sectors and deadlines change frequently: confirm the current position for each legal entity before committing a plan.
Recent Changes Worth Knowing
GİB moved e-Fatura and e-İrsaliye to a new central application
The low-value threshold for e-Arşiv invoices was removed: every invoice is electronic
Updated e-Fatura and e-Arşiv technical packages (UBL-TR 1.2.1 schemas) became mandatory
Documents may also be issued through new-generation payment recording devices at the point of sale
What This Means in Practice
Your customer must be registered to receive an e-Fatura; if not, the same sale becomes an e-Arşiv invoice. Registration status changes daily — the check is a system function, not a master-data note. Commercial-type invoices can be accepted or rejected by the buyer within a short statutory window; cancellations run through GİB's central service. Penalties are assessed per document, as a percentage of the invoice value with a statutory minimum. Records must be kept for up to 10 years, and archiving outside Türkiye is not permitted.
How a Turkish Invoice Travels
Every outbound document follows the same spine: create in UBL-TR, sign with the financial seal, clear through GİB, deliver, and bring the response back into the system that created it.
From SAP to the Customer, Step by Step
- SAP S/4HANA: billing, delivery or FI creates the eDocument.
- Integrator or your direct connection: UBL-TR, seal, transmission, archive and status.
- GİB: validation, clearance and mailbox routing.
- Customer's registered mailbox: accepts or rejects.
Response and status come back to the eDocument Cockpit: cleared · delivered · accepted · rejected.
e-Arşiv: when the customer is not registered, the invoice is delivered directly (e-mail or portal) and the data is reported to GİB by the next day.
Which Document Is It?
The system checks whether the counterparty is registered. Registered → e-Fatura and clearance. Not registered → e-Arşiv, delivered directly and reported. The check must run at invoicing time.
Basic or Commercial?
A temel (basic) invoice is simply delivered. A ticari (commercial) invoice can be accepted or rejected by the buyer within the statutory window — so your receivables process needs to handle a rejection.
Inbound Is Symmetrical
Supplier invoices arrive in your mailbox as structured documents. They must be fetched, posted, and — for commercial invoices — answered in time, or silence becomes acceptance.
The Statuses You Will Live With
The document exists and has been sealed, but has not been cleared. Watch for documents stuck here — it usually means connectivity or certificates.
Transmitted to the integrator or GİB, awaiting a response. Alert on anything unanswered beyond a few minutes.
Validated and accepted into the system. The point at which billing — or despatch — may proceed.
Placed in the counterparty's mailbox. Evidence for commercial disputes about receipt.
The buyer's answer to a commercial invoice. Rejections need a receivables process, not an inbox.
Validation, schema or connection failure. Fix and resend; recurring codes point to a mapping or master-data defect.
Where Projects Actually Stumble
It is seldom the XML. It is the e-delivery note timing (approval before the goods move, including sample shipments and plant-to-plant transfers), the cancellation and rejection windows, and the day a certificate or connection fails and nobody owns the recovery.
Routes to GİB: Integrator, Direct Integration and EDI
Türkiye recognises three ways of using the system, and most SAP customers of any size end up on the same one: a licensed private integrator, with EDI running alongside for partner traffic.
Manual entry or upload on the tax administration's own portal.
A licensed provider — Sovos, for example — formats, signs, transmits, archives and returns statuses, with SAP-certified connectors.
Your own systems connect to GİB services under your own licence, with your own seal and infrastructure.
Partner-to-partner exchange of orders, despatch advices and invoice data, usually converted into UBL-TR for clearance.
What a Private Integrator Does for You
- Converts your data into UBL-TR and validates it against the current technical package.
- Signs the document with the financial seal and transmits it to GİB.
- Routes it to the buyer's mailbox and brings back clearance, delivery and acceptance statuses.
- Delivers e-Arşiv invoices to customers and reports them to GİB.
- Provides the legal archive inside Türkiye for the retention period.
What to Pin Down in the Contract
- Which documents are in scope: e-Fatura, e-Arşiv, e-İrsaliye, e-Defter, and the smaller receipt types.
- Whose seal signs, and where it is held.
- SAP connector: certified, supported, and who maintains it through upgrades.
- Service levels for clearance delays, plus the escalation path when GİB is unavailable.
- Archive access, export format and what happens at the end of the contract.
- How schema updates — like the February 2026 package — are delivered and tested.
Where EDI Fits
| Flow | Channel | Note |
|---|---|---|
| Purchase orders, despatch advices, receipt confirmations | EDI with the trading partner | Commercial data; outside the tax system. |
| Invoice to a registered Turkish customer | EDI data feeds the invoice, which is cleared as e-Fatura | The cleared UBL-TR document is the invoice; the EDI copy is not. |
| Invoice to an unregistered or foreign customer | e-Arşiv, plus EDI or PDF for the partner's own processing | The reporting obligation stays with you. |
| Goods movement | e-İrsaliye through the tax system; EDI despatch advice to the partner | Two documents, one event — keep them consistent. |
Certificates: the Part that Stops Billing
Two different things are called 'the certificate' in Turkish projects, and confusing them costs weeks. One signs documents; the other secures the connection. You need both, they come from different places, and they expire on different days.
1 · Signing — Financial Seal (Mali Mühür)
- A qualified certificate issued to the legal entity by the state certification authority (TÜBİTAK BİLGEM Kamu SM), applied for through its portal against the tax number — delivery takes time.
- It signs e-Fatura, e-Arşiv, e-İrsaliye and the e-Defter summary files — a document without a valid seal is not a document.
- Delivered on a hardware token, or held in an HSM for server-side signing at volume.
- Issued per legal entity: every company code that invoices needs its own, ordered early.
- Sole traders and individuals use a qualified personal e-signature (e-imza) instead.
- It has a fixed validity: renewal must be planned, not discovered.
2 · Connectivity — TLS Certificates
- Server certificates of the integrator or GİB services, so your SAP system trusts the endpoint.
- A client certificate where the provider requires mutual TLS, so the endpoint trusts your system.
- Maintained in SAP with transaction STRUST: the provider's root and intermediate certificates go into the trust list; the client certificate goes into the SSL client PSE.
- The same applies in SAP Integration Suite or whatever middleware sits in between — in both directions.
- Renewal is an operations task with a change window: a silent expiry looks exactly like an outage.
Who Signs, and Where the Seal Lives
The provider applies the seal on your behalf under the authorisation you grant, typically from an HSM in its data centre. What you own: authorisation, seal ownership and renewal, and evidence that signing happened.
Signing happens on your side (token or HSM) before the document leaves. What you own: key custody, signing service availability, HSM operations.
You sign and transmit to GİB yourself. What you own: everything — seal, TLS, endpoints, schema updates and support.
The Certificate Checklist for a Turkish Go-Live
- Financial seal ordered per legal entity, with the tax number verified against the registry.
- Named owner for each certificate, with expiry dates in a monitored calendar.
- Decision recorded on who signs, and the authorisation in place if it is the provider.
- Test environment credentials and certificates separate from production.
- Provider root and intermediate certificates imported into SAP and the middleware.
- Client certificate installed where mutual TLS is required, and rotation rehearsed once.
- Firewall and proxy rules documented, including the outbound addresses used.
- A tested fallback: what billing and shipping do during an outage, and who decides.
The Failure You Can Predict
The most common production incident in Turkish e-document landscapes is an expired certificate — seal or TLS — usually noticed when invoices stop clearing or trucks cannot leave. It is entirely preventable with an owner, a calendar and a rehearsed renewal.
Connecting SAP S/4HANA
SAP Document and Reporting Compliance (DRC) provides the Turkish scenarios: the billing document or delivery creates an eDocument, the data is mapped to UBL-TR, and the document is sent through middleware to the integrator or to GİB. Everything is monitored in the eDocument Cockpit and the Manage Electronic Documents app.
The Architecture at a Glance
- SAP S/4HANA: SD billing, MM, FI, deliveries and goods issue, through the eDocument framework.
- Mapping and monitor: UBL-TR mapping (AIF), eDocument Cockpit and Manage Electronic Documents.
- Connectivity: SAP Integration Suite / BTP or partner middleware, with TLS, certificates and retries.
- Integrator → GİB: seal, clearance, delivery, archive in Türkiye, statuses returned.
Outbound: billing → eDocument → UBL-TR → clearance. Inbound: supplier documents return along the same path, and statuses, responses and inbound documents flow back into the cockpit.
What Has to Be Set Up
Activate the Turkish eDocument processes per company code and document type. Watch out: notes and support packages that do not match your release.
Map billing, delivery and FI data to UBL-TR fields, including tax codes. Watch out: withholding, exemptions and special consumption tax, which drive most of the effort.
Keep the registered-taxpayer list current so the system picks e-Fatura or e-Arşiv correctly. Watch out: a stale list sends the wrong document type — and the invoice is rejected or misfiled.
Tax number (VKN/TCKN), tax office, addresses, mailbox alias per customer. Watch out: aliases change; treat them as operational data with an owner.
Middleware flows to the provider, with retries and alerting; certificates as in the certificates section. Watch out: silent failures — a queue that stops without an alert stops invoicing.
Fetch supplier documents, post them, and answer commercial invoices within the window. Watch out: acceptance by silence — a missed rejection deadline is a booked cost.
Generate ledgers and summary files, sign and upload on the statutory cycle. Watch out: period-close dependency — ledger errors surface long after the invoices that caused them.
Retain documents and responses for the statutory period. Watch out: archiving abroad is not permitted — confirm where your provider and any cloud archive store the data.
Installing the Certificates in SAP, Step by Step
- Collect the endpoint's root and intermediate certificates from your integrator (test and production are usually different).
- Import them into the SAP trust list in transaction STRUST, under the SSL client identity used for the connection.
- Where mutual TLS applies, install the client certificate in the SSL client PSE and share its public part with the provider.
- Restart or refresh the ICM so the new trust takes effect, in a planned window.
- Point the connection destination at the provider's endpoint with the right SSL identity, then run a connection test.
- Repeat the same set-up in middleware — trust and identity live on both hops.
- Register the financial seal where it will be used: with the integrator under authorisation, or in your own token or HSM.
- Record every certificate, its owner and its expiry in a monitored register, and rehearse one renewal before go-live.
Note for Multinational Landscapes
Türkiye is usually the exception in a global SAP template: local schema updates, a local archive, a local provider and a local certificate regime. Design it as a country layer, not a fork, so the next mandate does not start from zero.
Running It: Processes, Roles and Pitfalls
The e-delivery note changes the warehouse, not just finance. Every physical movement is in scope, including samples, returns and plant-to-plant transfers that many templates never modelled as deliveries. Clearance takes seconds when everything works — and blocks the loading bay when it does not, so an exception procedure is part of the design.
The e-Delivery Note in Five Steps
- Plan: delivery created in SAP, before loading.
- Issue: e-İrsaliye generated and sent for clearance.
- Clear: GİB approval returns — the gate for despatch.
- Ship: goods leave with the approved document.
- Confirm: the customer's receipt response closes the loop.
What Changes, by Role
Compliance is an availability question: billing and shipping depend on a live connection and valid certificates. Decisions: integrator selection and contract, budget, sponsor, escalation path.
Document types, withholding and exemption cases, e-Defter cycle and its evidence. Decisions: ownership of e-Defter, archive strategy, correction and cancellation policy.
Rejections of commercial invoices come back as a process, not an e-mail. Decisions: who handles rejections, and within what deadline.
Supplier documents arrive structured; the response window is short. Decisions: automation target, and the rule for rejecting rather than accepting by silence.
Despatch depends on clearance of the e-delivery note. Decisions: exception handling when clearance is delayed, and cut-off times per shift.
Certificates, middleware, monitoring, schema updates and support packages. Decisions: named certificate owner, alerting, and the annual update cycle.
The Operating Rhythm
Hourly
Watch the outbound queue on despatch days — an unanswered delivery note is a truck waiting.
Daily
Clear the error backlog, answer inbound commercial invoices, check the counterparty list refresh.
Monthly
Reconcile issued documents against billing and the ledgers; run the e-Defter cycle and keep its evidence.
Yearly
Certificate renewals, technical package updates, integrator service review.
An Exception Playbook, Agreed in Advance
Define the wait before escalation, who calls the integrator, and whether despatch holds or switches to the agreed fallback.
Named owner per error type, a correction path back to billing or master data, and a daily review of anything unresolved.
Who declares it, what finance and the warehouse do meanwhile, and how the backlog is released in order once it returns.
Pitfalls We See Repeatedly
- Certificates without an owner — the single largest cause of production incidents.
- Stale counterparty lists sending e-Arşiv where e-Fatura was due, or the reverse.
- Deliveries not modelled for samples, returns and stock transfers.
- Cancellation and rejection windows missed because nobody watches the inbound queue.
- Schema updates treated as provider news rather than a tested change (the February 2026 package caught several landscapes out).
- Archive assumed to be the provider's problem, until the contract ends.
- No rehearsed outage procedure, so the first GİB incident becomes an improvisation.
- Türkiye forked from the template, making every later mandate a new project.
How 30 Advisory Can Help
A founder-led boutique specialised in SAP DRC & e-invoicing compliance, S/4HANA Finance optimisation and CFO/CIO strategic advisory, with SAP DRC delivery experience in France and Germany.
Readiness assessment and route decision
Readiness assessment: entities, document types in scope, current integrator and connection, certificate inventory and expiry dates. Route decision: integrator versus direct integration, and how EDI traffic fits alongside clearance.
Fit-gap against the current technical packages
Fit-gap against the current technical packages; mapping design for local tax cases, withholding and exemptions. Process design for e-delivery notes across every physical movement, and for inbound responses.
SAP DRC configuration and UBL-TR mapping
SAP DRC configuration, UBL-TR mapping, middleware flows, certificate installation and monitoring. Inbound automation into invoice verification, plus the e-Defter cycle with its evidence.
Testing in the GİB test environment and with the integrator
Testing in the GİB test environment and with the integrator: clearance, rejections, cancellations, outages. Cut-over, training for finance and logistics, and a rehearsed contingency procedure.
Ongoing monitoring and roadmap alignment
Ongoing compliance monitoring: schema packages, SAP notes, certificate renewals, KPIs and hypercare. Roadmap alignment with Spain, France and ViDA so Türkiye stays part of one template.
Already Live in Türkiye?
A short health check covers certificates and expiry, failed-document backlog, counterparty list freshness, e-delivery exceptions and archive terms — the five things that usually need attention first.
Typical Deliverables
Gap and Risk List
Per entity and document type, with effort and owner.
Certificate Register
Seals and TLS certificates, owners, expiry and renewal plan.
SAP Design
Mapping, connectivity, inbound, archiving and monitoring.
Test and Cut-over Plan
Including outage and rejection scenarios.
Founder-led
Finance + SAP DRC depth
SAP DRC delivery: France and Germany
Boutique agility
A Practical Implementation Path
Whether you are starting in Türkiye or repairing a landscape that already runs, the sequence is the same — and the certificate work starts on day one because it has the longest lead time.
Confirm obligations, choose the route, order financial seals
Confirm obligations per legal entity; choose the route; order financial seals; sign the integrator contract; agree who signs.
Exit criteria: seals ordered, contract signed, scope agreed per document type.
UBL-TR mapping, counterparty check, delivery-note process
UBL-TR mapping including local tax cases; counterparty check; delivery-note process for every physical movement; archive and retention design.
Exit criteria: design signed off by tax, finance, logistics and IT.
DRC activation, middleware flows, certificates
DRC activation and configuration; middleware flows; certificate installation; monitoring and alerting; inbound processing.
Exit criteria: an end-to-end document created, signed, cleared and returned in test.
Volume tests, rejections, outage simulation
Volume tests; rejections and cancellations; delivery-note timing under shift conditions; outage simulation; e-Defter cycle.
Exit criteria: every scenario, including failure paths, executed and documented.
Cut-over per company code, training, hypercare
Cut-over per company code; training for finance and warehouse; hypercare with daily monitoring.
Exit criteria: clearance rate and exception ageing stable for a full close cycle.
What to Measure Once It Runs
Clearance Rate
Documents cleared first time, by document type.
Time to Clear
Especially for delivery notes, measured against despatch cut-offs.
Exception Ageing
Failed or pending documents older than a day.
Response Timeliness
Inbound commercial invoices answered within the window.
Questions Worth Asking Your Team This Quarter
- When does each financial seal expire, and who renews it?
- How many documents are sitting in error right now, and since when?
- If clearance stopped for two hours at 16:00, what would the warehouse do?
- Where exactly is our archive held, and can we export it?
- Who confirmed we are on the February 2026 technical package?
- Do we answer inbound commercial invoices, or accept them by silence?
Who Needs to Be in the Room
Local Finance and Tax
Document types, tax cases, e-Defter ownership and the local calendar.
Logistics
Despatch cut-offs, sample and transfer flows, exception handling on the floor.
SAP and Basis
DRC, middleware, certificates, monitoring and the update cycle.
Integrator
Connectivity, signing, archive and the schema packages they deliver.
If Türkiye is one of several mandates in your group, sequence the work so the shared parts — master data quality, document mapping discipline, monitoring and archiving standards — are built once. The country-specific layers then get thinner with each mandate rather than thicker.
Who Does What
Obligations per entity, thresholds, document types. Withholding and exemption treatment; e-Defter rules.
Clearance connectivity, signing, delivery and archive. Schema updates and their delivery into your landscape.
Evidence of issuance, clearance and retention. Controls over exceptions and cancellations.
SAP design, build and run; certificate and monitoring discipline. Keeping Türkiye inside one global template.
Key Dates
New central application for e-Fatura and e-İrsaliye
Low-value exemption for e-Arşiv removed — every invoice electronic
Updated e-Fatura and e-Arşiv technical packages mandatory
France: SME issuing wave (for groups with French entities)
Spain: B2B mandate starts above €8M turnover
EU ViDA cross-border digital reporting
Next Steps
- Build the certificate register — seals and TLS, owners and expiry dates.
- Confirm obligations per entity and which document types are live.
- Review the integrator contract: scope, service levels, archive and exit.
- Clear the exception backlog and put daily monitoring in place.
- Rehearse an outage for billing and despatch, and write down the decision rights.
- Fold Türkiye into the group template before the next mandate lands.
What a First Conversation Needs from You
Entities
Turkish legal entities and which documents each issues.
Volumes
Invoices and delivery notes per month, and peak days.
Systems
SAP release, DRC status, integrator and middleware in place.
Pain Points
Failed documents, delivery-note timing, certificate incidents.
Mandate: Turkish Revenue Administration (GİB) e-document framework under the Tax Procedure Law General Communiqués; practitioner and advisory summaries of thresholds, document types, the December 2024 central application, the removal of the e-Arşiv low-value threshold from 1 January 2026 and the technical packages effective 2 February 2026 (UBL-TR 1.2.1). Retention: up to 10 years, with archiving abroad not permitted. Certificates: financial seal (mali mühür) and qualified e-signature issued through the state certification authority (TÜBİTAK BİLGEM Kamu SM); SAP guidance on trust lists and SSL client certificates (transaction STRUST). SAP & providers: SAP Document and Reporting Compliance documentation and partner material for the Turkish scenarios; Sovos published product information for Türkiye. Scope, licensing and release details must be confirmed with SAP and your integrator.
Prepared by 30 Advisory, September 2026. Information only — not legal or tax advice. Thresholds, deadlines and technical packages change frequently; confirm current figures with your Turkish tax advisor and integrator before acting. 30 Advisory accepts no liability for decisions taken on the basis of this document.
Not Sure What This Means for Your SAP Landscape?
We'll map your certificates, connection route and S/4HANA roadmap against the Turkish clearance system in our free 60-minute diagnostic.
Three things to check first
- A certificate register: seals and TLS, owners and expiry dates.
- The exception backlog, and who checks it every day.
- What billing and despatch do if the connection goes down.
Want the full picture? Score your DRC readiness →