Türkiye · e-Belge

e-Fatura on self-hosted Akaunting: what exists, what does not, and what has to be tested first.

There are two first-party Turkish e-invoice modules in the App Store, and both cover e-Fatura and e-Arşiv only. Whether either still authenticates against its integrator today is not something we will claim without testing it. That test is the first thing we sell, and it is deliberately cheap.

Book an e-Fatura assessment Talk about a connector

The inventory

GİB defines a list of e-documents. The App Store addresses two of them.

This is a list, not a pitch. On the left is what an existing module already handles. On the right is what has no Akaunting module at all — which means a connector build, a manual process, or a different tool for that document type. Knowing which column your requirement sits in changes the budget by an order of magnitude.

A module exists

e-Fatura: Two first-party modules, both published by Akaunting Inc.: one for Foriba, one for NES Bilgi.
e-Arşiv Fatura: The same two modules. Together, this is the full extent of Turkish coverage in the App Store.

No module exists

e-İrsaliye: Defined by GİB, sold by Turkish integrators, absent from the App Store entirely.
e-SMM: Serbest meslek makbuzu. Nothing in the App Store addresses it.
e-Müstahsil Makbuzu: Same position: a GİB document type with no Akaunting module behind it.
e-Defter: A different discipline from invoicing, and not covered by anything in the store.
e-Adisyon, e-Gider Pusulası, e-Dekont: Each has its own mevzuat and its own özel entegratör list at GİB. None has a module.

The governing instrument is VUK Genel Tebliği Sıra No: 509, as amended by Sıra No: 573. We are not going to print obligation thresholds or tevkifat ratios on a marketing page — they change, and the ones that apply to your company have to be read fresh against the tebliğ in force, with your mali müşavir. Anyone quoting you a threshold from memory is quoting you a number they have not checked.

Start here, always

First we find out whether the module you were about to buy still works.

Here is what we know, and it is deliberately less than a sales page would claim. The domain foriba.com now serves Sovos Türkiye content, because the Foriba brand was absorbed into Sovos; the App Store still lists the module under the retired name. Neither Turkish module publishes a version number or a changelog. The Turkish forum has a thread asking whether the NES module still works, and it has no replies. None of that proves anything is broken. All of it means nobody can honestly tell you it works, including us, until it has been tested.

A run against each integrator's test environment, with the request and the response captured rather than summarised
A written verdict per module: use it as shipped, patch it, or build a connector instead
Which integrator to sign with and why, including whether they publish REST documentation and run a software-partner track
The document types you actually need, mapped against what the modules cover and what they do not
What your mali müşavir needs to see before anything real is sent to GİB
A cost and a duration for whichever route the verdict points at

Fixed price, one to two weeks. Credited into the connector build if that is where it lands — and if the verdict is that the stock module works fine, that is the cheapest possible outcome and we will say so in writing.

Two Turkey problems that are not e-invoicing

Tevkifat and the chart of accounts. Different problems, very different prices.

Both get bundled into "e-Fatura work" by vendors who have not looked at either. One is a two-day configuration job. The other needs your mali müşavir in the room.

Tevkifat

Akaunting core does have a withholding tax type — the Turkish strings call it Stopaj — and we have read the calculation: it applies a negative percentage to the line's taxable base. That models a gelir vergisi stopajı reasonably well. KDV tevkifatı is a different shape entirely: a ratio applied to the KDV amount rather than to the base, liability split between buyer and seller, a GİB tevkifat code, and separate hesaplanan KDV and tevkifat lines on the UBL-TR document. Neither Turkish module claims to handle it. So this is configuration where core can express it and a module where it cannot — scoped jointly with your mali müşavir against the tebliğ in force at the time, and priced after that scoping rather than before it.

TDHP chart of accounts

The Double-Entry app's chart of accounts is built on Anglo-Saxon types and classes, and nothing in it maps to Tek Düzen Hesap Planı's numbered structure. The good news is that the chart is importable through a documented four-sheet Excel file with free-text codes, so a TDHP-coded chart with the KDV rate set and the category structure is a configuration job with no code in it at all. It is the cheapest real win in this whole service line. What it gives you is TDHP codes and hierarchy — it does not give you a mizan your YMM will sign without reading it, and we are not going to imply otherwise.

The work, separated

Five units, priced separately, because the risks are not comparable.

Bundling a two-day chart-of-accounts import together with a connector build against a platform GİB is currently migrating would be convenient for us and bad for you.

Turkey localisation and e-documents

Buy them in this order, unless you already know the answer to the one above.

1
e-Fatura durum tespitiFixed price · 1–2 weeks
The assessment above. Test environment, captured requests, a written verdict per module and an integrator recommendation. Always first, and cheap on purpose.
2
e-Belge connector buildPaid discovery, then fixed price per document type
For whatever the assessment shows is missing — most often e-İrsaliye, e-SMM or e-Müstahsil Makbuzu, none of which has a module. Built against an integrator that publishes REST documentation and runs a partner track, with UBL-TR mapping, status polling, inbound document handling, retries and an audit log. The second document type on the same connector costs materially less than the first.
3
TDHP hesap planı paketiFixed price · 2–5 days
A TDHP-coded chart of accounts, the KDV rate set and the category structure, delivered through the documented Excel import. No code at all. Optional review session with your mali müşavir, which we recommend taking.
4
Tevkifat and KDVFixed price after joint scoping
Configuration where core can express it, a module where it cannot. Scoped with your mali müşavir, because the ratios and the covered service list live in the tebliğ and they move. We will not quote this from a description.
5
Paid-app translationFixed price per app · about a week for a typical set
Core Turkish is already complete — key for key with English, in correct accounting Turkish — so we do not sell that and it would be dishonest to try. What is not translated is the paid apps: Double-Entry, Inventory, CRM, Payroll, Projects. That is why half your interface is still in English. Includes the date and calendar locale gaps, and the currency symbol position, which is a setting rather than a bug.

Talk about which one you need

What we promise, and what we will not

The line between our job and your mali müşavir's.

This distinction is the most important thing on the page, so it gets a section rather than a footnote. Every vendor that blurs it is transferring a risk to you quietly.

We take responsibility for

A working integration: documents leave your Akaunting, reach the integrator, and come back with a status you can see in the interface
Keeping it working: retries, error handling, an audit log, and a maintenance line — GİB is currently migrating its e-Fatura and e-İrsaliye central application, which is exactly when unmaintained connectors fail
The mapping between what Akaunting stores and what the UBL-TR document requires
Telling you when the honest answer is a different tool for that document type, rather than a module we would enjoy building
Testing against the integrator's test environment before anything real is sent

We do not promise, and will not write

"GİB uyumluluğu" or GİB compliance as a guarantee. Compliance is a fiscal opinion; we build the integration and your mali müşavir gives the opinion.
Obligation thresholds or tevkifat ratios, on this page or in a proposal. They change by tebliğ and have to be read fresh for your company.
That the existing Foriba or NES Bilgi module works today. We have not tested it against a live integrator, and until somebody has, neither has anyone telling you otherwise.
e-Defter. It is a separate discipline and we would be learning it on your money.
Signing anything on your behalf, or holding your e-İmza.

How it is priced

Assessment first, then per document type.

Integrator scope is knowable up front, which means an open-ended quote for a connector is a choice rather than a necessity.

Assessment

Quoted after assessment

The durum tespiti. Fixed price, one to two weeks, and the fee comes off whatever you buy next. The cheapest possible outcome is a verdict that says the stock module is fine.

Written verdict per module
Integrator recommendation
Credited into the build

Connector, per document type

Quoted after assessment

Fixed price after a paid discovery, per document type, on a connector we then maintain. Priced after discovery rather than before, because that is when the integrator's API stops being a guess.

Discovery 1–2 weeks
First document type 4–8 weeks
Later types materially cheaper

Compliance retainer

Quoted after assessment

For anything connected to GİB. The platform is moving and the tebliğ moves with it, so a connector without a maintenance line is a liability we are not willing to hand over quietly.

Tracked against integrator changes
Included in the maintenance retainer
Monthly written report

Invoicing entity: Lokum Tech LLC

Integrator contract and e-İmza stay in your name

Scoped with your mali müşavir where fiscal treatment is involved

Written scope before any work begins

Starting prices for these packages are being finalised. Ask on a call and we will give you a number, not a range.

Straight answers

Questions about e-Fatura and Akaunting.

Can you make our Akaunting GİB compliant?

No, and neither can anybody else, because compliance is not a software property. It is a fiscal position about your company: which documents you are obliged to issue, in what form, with what treatment. Your mali müşavir owns that. What we can do is build and maintain an integration that produces the documents they tell us to produce and sends them through a licensed integrator, and test it before anything real goes out. Any vendor selling you "GİB uyumluluğu" as a feature is selling you a sentence, not a system.

There is already an e-Fatura module in the App Store. Why do we need an assessment?

Because nobody can currently tell you it works. The Foriba brand has been absorbed into Sovos and its old domain now serves Sovos content, while the App Store still sells the module under the retired name. Neither Turkish module publishes a version or a changelog. A Turkish forum thread asking whether the NES module still works has no replies. Those are signals, not proof of breakage — which is precisely why the answer is a test rather than an opinion, and why the test is priced to be an easy first purchase.

Which integrator should we use?

If you already have one and your mali müşavir is happy with them, that is usually the answer and we will build against them. If you are choosing, the criteria we care about are publicly documented REST APIs, a usable test environment, a software-partner track, and the document types you will need next year rather than only the ones you need now. At least one Turkish integrator publishes all of that openly, which makes it a straightforward technical choice — but it is your commercial relationship, in your name, not ours.

We need e-İrsaliye. Is there a module?

No. Not for e-İrsaliye, e-SMM, e-Müstahsil Makbuzu or e-Defter — the App Store's Turkish coverage stops at e-Fatura and e-Arşiv. So this is a connector build: a paid discovery against your integrator's API, then a fixed price for the first document type, with subsequent types materially cheaper on the same connector. It is real work and we will not pretend it is a configuration change.

Can you fix the Turkish translation?

The core product does not need fixing, and we are not going to sell you that. Its Turkish files are complete — key for key with English — and the accounting terminology in them is correct. What is genuinely missing is the paid apps: Double-Entry, Inventory, CRM, Payroll, Projects. Their strings are not in the shared translation platform, which is why your interface goes half-English the moment you install them. That part we do sell, per app.

Do we need our mali müşavir involved?

For the connector, briefly. For tevkifat and the chart of accounts, properly. We need them to tell us the treatment, the document types, and what they need to see in order to sign off — and we would rather have that in writing at the start than discover a disagreement after the first document has gone to GİB. We will join the call, take the notes, and build to what they say. What we will not do is substitute our judgement for theirs.

Every good build starts with a conversation.

Tell us the process that hurts. We will tell you honestly whether we are the right studio for it — and if we are not, who is.

Book a 30-minute call Who does the work