Tecof • September 22, 2026
e-Fatura and e-Arşiv: E-commerce Setup and the GİB Process
In Brief
e-Fatura and e-Arşiv are two different electronic document types that replace the paper invoice in Turkey: an e-Fatura travels through the Revenue Administration's (GİB) infrastructure between two taxpayers registered in that system, while an e-Arşiv invoice is issued to recipients who are not registered — that is, to most end consumers in e-commerce — and reported to GİB. In an online store the overwhelming majority of sales fall into the second group, but the first group activates the moment a corporate buyer appears; that is why the two should be built as a single flow, not as two separate projects. As of 2026 the question is not "am I obliged to move to e-invoicing" but "after an order is confirmed, in how many seconds, with which fields, and with what happens when something errors, does the invoice come into existence".
Wednesday morning, 09.20. The accounting team of a home textiles store sees 287 invoices in the system against the previous day's 312 orders. Of the 25 missing invoices, 18 are orders where the buyer entered a tax number but the system did not recognise that buyer as registered for e-Fatura; 5 are records the integrator rejected because an e-Arşiv invoice was attempted for a corporate buyer; and 2 are requests created at the moment the integrator's API failed to respond for 14 seconds and were never retried. The team closes this gap by hand every morning and spends an average of 40 minutes a day doing it.
The cause was one missing piece of architecture: the invoice request had been embedded inside the order flow, synchronously and with a single attempt. Which document type the buyer was subject to was never queried at order time, and failed requests were never queued. When the same job is rebuilt with a queue, a taxpayer lookup and a retry rule, 40 minutes of daily manual work drops to reviewing a handful of exceptions a week. Most e-invoicing projects hurt not because of the regulation but because of those three gaps.
Everything below describes the mechanism; items such as rates, deadlines and penalty amounts change with the legislation. Confirm the current state of your obligation and the thresholds that apply to you with your own accountant.
1. What Is the Difference Between e-Fatura and e-Arşiv?
The only thing that determines the difference is the recipient: if the buyer is registered in GİB's e-Fatura system you issue an e-Fatura, and if not you issue an e-Arşiv invoice. The content of the document, its legal validity and the retention obligation are largely the same; what differs is the route by which the document reaches the other party.
Who issues an e-Fatura, and to whom?
An e-Fatura is a document that travels between two registered parties over GİB's infrastructure. It is not "emailed" to the buyer; it is deposited into the system, lands in the buyer's inbox there, and the buyer responds to it with an acceptance or a rejection. That has two consequences for e-commerce: first, you need to know whether the buyer is registered before you issue the invoice; second, because the document appears inside the other party's own system, the "the customer never received the invoice" argument largely disappears.
When does an e-Arşiv invoice come into play?
An e-Arşiv invoice is issued to buyers who are not registered in the e-Fatura system, stored electronically and reported to GİB. Every sale to an end consumer falls into this group. It can be delivered to the buyer as a PDF by email, or printed and placed in the parcel if they ask for that. GİB also defines an obligation for businesses that are not e-Fatura taxpayers to issue e-Arşiv invoices for sales above a certain amount; because that monetary threshold is an item that gets updated, confirm its current value with your accountant.
e-İrsaliye and the other e-documents
In e-commerce the invoice alone is not enough; documents on the shipping, returns and collection side also go electronic.
- e-İrsaliye: the electronic waybill that accompanies the physical shipment of goods. It keeps the flow standing when the moment of dispatch and the moment of invoicing are separated — for example on cash-on-delivery sales.
- e-Arşiv return invoice: on returns from end consumers, the document the seller issues itself, because the buyer cannot issue an invoice.
- e-Serbest meslek makbuzu and e-müstahsil makbuzu: used for professional services and for buying directly from producers; relevant for stores working with agencies on the marketplace and content production side.
- e-Defter: the bookkeeping side rather than the document side; it arrives alongside the e-Fatura obligation and is usually planned on the same calendar.
| Document | Recipient | Delivery route | Typical use in e-commerce |
|---|---|---|---|
| e-Fatura | Registered taxpayer | GİB infrastructure | Corporate / B2B orders |
| e-Arşiv invoice | Unregistered buyer, consumer | Email, printout | Most retail orders |
| e-İrsaliye | Buyer and carrier | GİB infrastructure | When dispatch precedes the invoice |
| e-Arşiv return invoice | Issued by the seller itself | Email, record | Distance-selling returns |
2. How Does the Obligation Arise in E-commerce?
The obligation arises in one of two ways: by crossing a revenue threshold, or by your line of business being brought into scope. Because businesses selling over the internet can fall into scope-based obligation even with low revenue, in e-commerce that second route is the more decisive one.
Revenue thresholds and activity-based obligation
GİB brings taxpayers whose gross sales revenue exceeds a certain amount into e-Fatura scope, and lowers that threshold over time. Alongside that, there is a separate scope definition for those selling goods and services over the internet and for intermediary service providers. Because thresholds and effective dates change through official communiqués, we give no figures here; check your own position with your accountant. What matters in practice is this: waiting to be formally notified that you have entered scope leaves too little time to prepare.
Where sellers on the internet stand
A business selling from its own site and a business selling on a marketplace stand in the same place as far as the obligation to issue the invoice goes: the seller invoices the customer. Even when the marketplace collects the money, it is not a party to the sale; it issues you a separate invoice for its own commission. Stores that miss this distinction lose weeks trying to reconcile the amount on the marketplace report with their own invoice total.
Does it make sense to switch before the obligation starts?
Usually yes, because the hard part of the transition is the integration, not the regulation. A store that moves before its obligation date learns the error scenarios at low volume; a store that moves on the obligation date learns the same errors during a campaign period. Procuring the financial seal, signing the integrator contract and working through the test environment also take up calendar space, and they cannot be squeezed into the same week.
3. Setup: Financial Seal, Application and Choosing a Method
Setup consists of three steps: obtaining the electronic signing instrument, applying to GİB, and choosing how invoices will be issued. They are done in that order, and the first step takes the longest.
Financial seal or electronic signature?
The instrument that signs the document depends on the taxpayer's legal form.
- Financial seal (mali mühür): the electronic certificate issued in the name of the organisation, used by legal entities — that is, companies. The application goes through the public certification service provider and delivery takes time.
- Qualified electronic signature (e-imza): usable by natural-person taxpayers, that is sole proprietorships; it belongs to the individual.
- Certificate validity: both the seal and the signature have a validity period, and when it expires invoicing stops. Noting the renewal date in the calendar prevents the single most irritating annual outage.
GİB portal, private integrator, direct integration
There are three ways to issue invoices, and volume decides the choice. The GİB portal is the free route where you enter invoices by hand; it is enough for a business issuing a few dozen invoices a month, but in e-commerce it becomes a bottleneck quickly because there is no automation. A private integrator (özel entegratör) is an intermediary authorised by GİB that lets you issue invoices through an API; this is the standard e-commerce solution. Direct integration means connecting your own server to GİB's system; it requires a technical team, an uptime commitment and certification, which makes it sensible only for very high-volume businesses.
Application order and the usual delays
The correct order is: apply for the financial seal, receive the seal, submit the e-Fatura and e-Arşiv applications through GİB, sign the integrator contract, run trials in the test environment, go live. The most common delay is the seal's delivery time; second is a flow that works in the test environment behaving differently in production. For that reason, do not schedule your go-live to coincide with a campaign period.
| Method | Suitable volume | Automation | Technical load | Cost item |
|---|---|---|---|---|
| GİB portal | Very low | None, manual entry | None | Free, high human time |
| Private integrator | Low to very high | Full, via API | Medium | Quota / package fee |
| Direct integration | Very high | Full, via API | High | Servers, team, certification |
4. Choosing an Integrator: What to Look At
What decides an integrator choice is not the price but the quality of the API and its behaviour when things fail, because the code that issues the invoice runs on your side while they are the party carrying the document to GİB. The headings below are the questions to ask before signing the contract.
Quota and pricing model
Pricing is usually built on an annual invoice quota, with extra packages bought once the quota runs out. Three questions to ask: is the quota counted separately for e-Fatura and e-Arşiv, do cancelled invoices come off the quota, and does unused quota carry over at year end. Because the daily invoice count can rise to several times the average during campaign periods, plan the quota against your busiest month's volume rather than the annual average.
API quality and documentation
Do the evaluation by reading the documentation, not by watching the demo screen. What to look for: does the test environment behave like production, do error responses carry a code and an explanation, is there an endpoint that queries whether the buyer is registered for e-Fatura, and does sending the same order twice produce a duplicate invoice. Without that lookup and that error structure, you carry the weight of the integration yourself. We covered the general logic of integrations in the article explaining how APIs work in e-commerce.
Support, SLA and archive access
When the invoice flow stops, sales stop too, because you cannot close an order without an invoice. So the support channel's working hours, its average response time and the existence of an incident status page matter more than a difference in price. Also get written confirmation of whether your invoices will be handed over to you in machine-readable form (XML) when the contract ends; the legal retention obligation stays with you, not with the integrator.
| Criterion | Good sign | Bad sign |
|---|---|---|
| Taxpayer lookup | Dedicated endpoint, current list | No lookup, learn by trying |
| Error responses | Code + explanation + field name | One line, "operation failed" |
| Test environment | Behaves like production | Screen demo only |
| Resubmission | No duplicate on the same reference | A new document on every request |
| Data export | Bulk XML and PDF download | One at a time from the panel |
5. Technical Integration: The Order-to-Invoice Flow
The correct flow is: payment is confirmed, the buyer's document type is queried, the invoice request is queued, the queue creates the document, the result is written back to the order record. Issuing the invoice synchronously inside the order request is the most expensive architectural decision in e-commerce.
At what moment the invoice is issued
The payment method determines the moment. With cards and online payment, issuing after payment approval is correct. With cash on delivery, collection is not final until the goods are handed over, so the flow is usually tied to dispatch and delivery information; that is the scenario where e-İrsaliye comes in. With bank transfer, issuing the invoice after reconciliation visibly reduces the number of cancellations. This decision should not be made by accounting alone or by the software side alone; both should settle it at the same table.
Mandatory fields and information specific to internet sales
Every invoice carries seller and buyer details, a document number and date, goods and service lines, tax amounts and totals. For sales made over the internet, the payment method, the payment date and information about the company carrying the shipment are additionally expected to appear on the document. In practice the field most often left empty is the carrier, because the courier is assigned after the order; building the flow so that the invoice is issued after the shipping information arrives solves that at the root. Confirm the current field set from your integrator's documentation and with your accountant.
Error handling, queues and duplicate protection
This section is the part that really decides the project.
- Queue: the invoice request should be processed in a queue separate from the order flow; when the integrator slows down, the customer should not see an "order could not be placed" screen.
- Retries: transient errors should be retried with increasing wait times, while permanent errors should leave the queue and land in front of a human.
- Duplicate protection: every request should be sent with a single reference derived from the order number; the same reference going twice must not create a new document.
- Reconciliation job: every day, the day's orders should be compared with the invoices issued and the difference written into a report. Without that report, missing invoices are noticed months later.
- Record keeping: the outgoing request and the incoming response should be stored together with the document number; in a dispute or an audit that record is your only ground to stand on.
Numbering and series management
The document number on an electronic invoice follows a standard pattern: a three-character series code, a four-digit year and a nine-digit sequential number. The number is produced by the system at the moment of issue, and no numbers are skipped. The practical consequence: using a separate series code per sales channel (your own site, marketplace, returns) makes reconciliation visibly easier. Coding on the product and variant side needs the same discipline; we covered how to build an SKU structure in a separate article.
6. Returns, Cancellation and Objection Processes
The rule on the returns side is this: if a sale is reversed after the invoice has been issued, the document is closed with a cancellation or a return document — the invoice itself is not deleted. Which route is used depends on whether the buyer is a taxpayer and on which stage the process has reached.
Return invoices in distance selling
Because an end consumer cannot issue an invoice, the seller issues the document for returned goods itself. In practice there are two routes: the buyer sends the printed invoice back along with the return form, or the seller creates the return document from its own records. We described how the whole returns flow is built, together with the courier and customer communication side, in our article on logistics and warehouse management.
Cancelling and objecting to an e-Fatura
Once an e-Fatura has been deposited into the system it cannot be deleted unilaterally. The buyer can turn the document away with a rejection; where there is a dispute between the parties, a notification is filed through GİB's cancellation and objection notification structure. Those notifications have time limits defined in the legislation, and when a deadline is missed the document stays in the accounting records. We do not give the periods here because they can change; settle this step with your accountant while building the flow, and measure how many hours it takes a cancellation request to reach your team.
Partial returns and shipping charges
When one item out of a three-item order is returned, the whole invoice is not cancelled; a document is issued for the returned line. Whether the shipping charge is included in the refund depends on how it was committed in your sales terms, and it must be visible on the document. In systems where campaign discounts are not distributed across lines, the partial refund amount is calculated wrongly; that is the single most common cause of refund disputes.
| Scenario | Invoice status | Action | What to watch |
|---|---|---|---|
| Cancelled before dispatch | Not yet issued | Do not create a document | Cancel the queued request |
| Consumer right of withdrawal | e-Arşiv issued | Issue a return document | Status of the shipping charge |
| Corporate buyer return | e-Fatura issued | Return invoice from the buyer | Tax details must match |
| Invoiced to the wrong buyer | e-Fatura issued | Cancellation / objection notice | The statutory time limit |
| Partial return | Invoice issued | Only the returned line | Discount split across lines |
7. Invoicing in Marketplace and Multichannel Sales
In multichannel selling the seller always issues the invoice; the marketplace's role is collection and intermediation. When that distinction is not clear, reconciliation work grows faster than the number of channels.
Who issues the invoice?
If you sell on marketplaces such as Trendyol or Hepsiburada, you issue the invoice to the customer, and getting the document to the customer along with the order is your responsibility. The commission invoice the marketplace issues to you is an entirely separate document and is booked on the expense side. In a store selling through three channels, using three separate invoice series brings month-end close down from days to hours.
Commission invoices and reconciliation
The amount on a marketplace settlement report will never match your own invoice total one to one, because commissions, service fees, returns and deductions sit in between. The correct method is to match at order level: for every order number, the invoice issued, the return document and the marketplace's deduction should appear on the same row. Doing that matching by hand is possible up to a three-digit order count; above that it needs automation. You can look at how channel and accounting connections are set up on the integration options page.
Cross-border sales and export invoices
A sale to a buyer abroad is subject to a different regime from a domestic sale and has to be built together with the customs side. The electronic export invoice is a separate flow that runs alongside the customs process, while small parcel shipments bring a different procedure into play. That subject deserves an article of its own and must be planned with your accountant; a flow set up wrongly while volumes are small becomes expensive to reverse once volumes grow.
Moving to e-Fatura and e-Arşiv in Thirty Days
Thirty days is a realistic period for a store starting from zero to go live, on one condition: the financial seal application is filed on day one. The order matters, because each step depends on the output of the one before it.
Days 1-7: application and diagnosis
File the financial seal application on the first day; its delivery time is the longest item on the calendar. In the same week, write down where you stand: monthly invoice count, the busiest day's invoice count, the share of corporate buyers, the return rate, the sales channels and the payment methods. Those five numbers determine both your integrator quota and the design of the flow. Nothing is built this week.
Days 8-14: integrator and test environment
Get quotes from at least two integrators and compare their documentation. As soon as the contract is signed, run three scenarios in the test environment: an e-Arşiv to an end consumer, an e-Fatura to a corporate buyer, and a return document. Test the taxpayer lookup endpoint this week; it is the most expensive thing to learn in production.
Days 15-21: building the flow
Move the invoice request into a queue, write the retry rule, and build duplicate protection on a reference derived from the order number. Settle the invoicing moment per payment method and decide where shipping information enters the flow. Set up the daily reconciliation report this week; nobody goes back and builds it after go-live.
Days 22-30: go-live and monitoring
Go live in stages rather than all at once: one channel for the first two days, then all channels. Look at the reconciliation report every morning and do not stop until the difference reaches zero. What you should hold on day thirty: a daily report that shows no gap, one person who knows what to do when something fails, and a reminder for the certificate renewal date in the calendar. How much of this a platform brings ready also matters; every step you have to build from zero adds a week to the transition calendar.
Here is the job for tomorrow morning: take the number of orders closed yesterday and compare it with the number of invoices issued yesterday; if the two numbers differ, open the records producing the gap one by one and write down at which step each broke. That single comparison usually surfaces a shortfall that has been building for months in about half an hour, and shows you where the integration needs strengthening. On an e-commerce platform where the invoice, payment and shipping flows come built in at template level, most of this job becomes configuration rather than construction.
Frequently Asked Questions
What is the difference between e-Fatura and e-Arşiv?
The recipient decides: if the buyer is a taxpayer registered in GİB's e-Fatura system you issue an e-Fatura, and if not you issue an e-Arşiv invoice. An e-Fatura lands in the other party's inbox inside the system; an e-Arşiv invoice is delivered to the buyer by email or as a printout and reported to GİB.
Does everyone doing e-commerce have to use e-Fatura?
The obligation arises either from crossing a revenue threshold or from your line of business being brought into scope, and there is a separate scope definition for those selling over the internet. Because thresholds and dates change through official communiqués, you need to confirm your own position with your accountant; in practice, switching ahead of the obligation date is less painful than waiting for it.
How long does it take to get a financial seal, and who needs one?
A financial seal is required for legal entities; natural-person taxpayers can use a qualified electronic signature. Delivery time varies with application volumes and is the longest item on the transition calendar, so the application should be filed on the project's first day. When the certificate's validity expires, invoicing stops — so the renewal date belongs in the calendar.
Should I use a private integrator, or is the GİB portal enough?
Because the GİB portal requires manual entry, it is only enough for businesses issuing a few dozen invoices a month. In e-commerce, where order counts are spread unevenly and multiply on campaign days, a private integrator working over an API is the standard solution. Direct integration makes sense only for very high volumes with an in-house technical team.
At which moment in the order should I issue the invoice?
It depends on the payment method: after payment approval for online payment, tied to dispatch and delivery for cash on delivery, and after reconciliation for bank transfer, which lowers the number of cancellations. Accounting and the software side should decide together, because choosing the wrong moment needlessly increases the number of cancellation and return documents.
What should I do if the customer entered their invoice details incorrectly?
An e-Fatura issued to a corporate buyer cannot be deleted unilaterally; the buyer can reject the document, or a notification is filed through GİB's cancellation and objection structure within the period the legislation allows. On an e-Arşiv invoice issued to an end consumer, the correction is usually made through a return document and a new invoice. Confirm the periods and the correct procedure with your accountant.
When selling on a marketplace, does the marketplace issue the invoice?
No — the seller invoices the customer; the marketplace collects payment and intermediates, and issues you a separate invoice for its own commission. That is why the amount on a marketplace settlement report will not match your own invoice total one to one, and why reconciliation has to be done at order-number level.
Do I also have to give the customer an e-Arşiv invoice on paper?
The electronic form is the definitive one and can be delivered to the buyer electronically; a printout can be provided when the buyer asks for it. In practice many stores email the invoice and put no printout in the parcel, while others do because corporate customers expect it. Measuring the expectation in your own sector and settling on one rule reduces the questions reaching customer service.
Does the e-Fatura obligation bring the e-Defter obligation with it?
These are separate regulations, but in practice they arrive together and are usually planned on the same calendar. Keep in mind that the document side and the bookkeeping side require different preparation: e-Fatura is an integration job, while e-Defter is an accounting-process job. Clarify which applies to you and when with your accountant.
How long do I have to keep my invoices, and whose responsibility is storage?
The legal retention obligation belongs to the taxpayer — to you; the integrator provides a service but does not assume the responsibility. That is why it matters to get written confirmation that your invoices will be delivered to you in bulk and in machine-readable form (XML) when the contract ends. Confirm the current retention period with your accountant and build the habit of taking an annual backup.