Turkey's e-Ledger (e-Defter) is the electronic form of the statutory journal and general ledger. Each month the books are produced as XBRL-GL files in the format set by the Revenue Administration (GİB), sealed with a financial seal or qualified e-signature, and confirmed by a GİB-approved summary file called a berat. It replaces paper ledgers and notary certification.
What is the e-Ledger in Turkey?
Under the Tax Procedure Law and the Turkish Commercial Code, companies must keep a journal (yevmiye defteri) and a general ledger (defter-i kebir). On paper, these were certified by a notary at the start of the year and closed at the end. The e-Ledger turns that ritual into a data exchange: your accounting software generates monthly ledger files in XBRL-GL, a global standard for general-ledger data, following GİB's Turkish taxonomy.
Legal entities sign the files with a financial seal (mali mühür); sole traders use a qualified electronic signature. For each period the software then creates a berat, a small file carrying a summary of the ledger and your signature. It is sent to GİB, which counter-signs it with its own seal. The approved berat proves that the books for that month were closed and have not been altered since.
Upload deadlines are set by communiqué. The general rule is the end of the third month after the month concerned, with different timing possible for the final period of the year, so confirm the current calendar with your local accountant. Retention works in two layers: the taxpayer keeps the ledger and berat files, and since 2020 secondary copies are also held on GİB systems. The Commercial Code requires books to be kept for ten years.
The e-Ledger is not an invoicing tool. e-Invoice integration in Turkey governs how a document reaches your customer; the e-Ledger governs how that document is recorded in your statutory books. Both draw on the same ERP data, but they answer different questions; for invoices to buyers outside the e-Invoice system, see our guide to e-Archive invoices in Turkey.
Who has to use it, and what changed in 2025
For years, the e-Ledger was mandatory mainly for e-Invoice users and companies above certain revenue thresholds. That changed sharply in 2025.
According to GİB's 2025 Annual Activity Report, the number of taxpayers using the e-Ledger rose from 781,584 in 2024 to 2,192,798 at the end of 2025.
The same report attributes the jump to Communiqué No. 5 on Electronic Ledgers, published on 8 November 2024. From 1 January 2025, every taxpayer required to keep books on a balance-sheet basis must use the e-Ledger. In practice, that covers virtually every limited and joint-stock company, including Turkish subsidiaries of foreign groups. Small businesses on single-entry bookkeeping and self-employed professionals usually use a separate system, the Ledger Declaration System (Defter Beyan Sistemi), which had 2.9 million active users at the end of 2025 according to the same GİB report. We cover the self-employed side in our guide to Turkey's e-SMM receipt.
The real issue: the e-Ledger mirrors your ERP data
Most companies discover the same thing in their first month: the software refuses to generate the file. The cause is rarely the e-Ledger itself. It is the data behind it. A journal entry missing a document type or number, a break in entry numbering, entries out of date order or an unbalanced entry will all fail the e-Ledger validation checks.
These errors usually come from fragmented processes. Sales live in the ERP, purchasing in another tool, bank movements in spreadsheets and expense receipts in email attachments. Every manual copy is a chance to get something wrong, and the point at which teams outgrow spreadsheets is usually felt hardest at month-end close. The same pattern appears in cooperatives that keep produce purchases and member settlements in separate programs; we show how to bring those records into one system in agricultural cooperative management software.
For international groups there is a second layer. The Turkish entity's books often sit in a group ERP configured for IFRS or another local GAAP, while the statutory ledger must follow the Turkish uniform chart of accounts. If that mapping is maintained by hand, the e-Ledger exposes every gap, every month. Keeping the mapping table in the system and versioning every change stops these errors at source.
The cost of getting it late or wrong
Volumes keep rising. GİB's 2025 Annual Activity Report shows 1,188,605,103 e-Invoices were issued in Turkey in 2025, and every one of them becomes an accounting entry somewhere. If incoming invoices are still keyed in by hand, OCR invoice processing or direct integration removes the single largest source of ledger errors.
A missed berat or a ledger that has to be regenerated costs more than a potential tax penalty. Correcting a closed period means cancellation, regeneration and back-and-forth with your accountant. Meanwhile, management waits for a current balance sheet and cash flow report until "the books are closed".
Choosing software is its own decision. The same GİB activity report notes that 219 commercial e-Ledger packages had passed the compliance tests by the end of 2025. Choice is not the problem; an approved package cannot fix poor data in your ERP. The real cost sits in a weak bridge between the two.
How to set up the e-Ledger: seven steps to a clean close
This sequence works both for first-time adopters and for teams that fight the same errors every month:
- Confirm scope in writing. Which entities and branches are in scope, will branches keep separate ledgers, and from which period? Agree this with your Turkish accountant.
- Prepare the signing infrastructure. Obtain the financial seal or qualified e-signature, put expiry dates in the calendar and name a backup owner.
- Choose the software route. Your ERP's own e-Ledger module or a separate provider? Ask concretely how data will move, whether through API integration or file transfer.
- Fix the chart of accounts and document types. Make document type, number and date mandatory fields on every journal entry in the ERP, and block unexplained use of the "other" document type.
- Connect day-to-day bookkeeping. Let invoice, bank and expense data flow into the general ledger without re-keying. Repetitive reconciliation is a good candidate for RPA process automation.
- Automate pre-close checks. The checks below should run as a report before any file is generated.
- Test storage and recovery. Document where ledger and berat files live and how many copies exist, and run a backup restore test at least once a year.
Pre-close checklist
| Check | Why it matters | Where to catch it |
|---|---|---|
| Continuous journal and voucher numbering | Gaps cause validation errors and audit questions | ERP close report |
| Document type, number and date present | Mandatory XBRL-GL fields | Mandatory field at entry |
| Chronological order | Back-dated entries cannot enter a closed period | Period lock |
| Debit and credit balance | An unbalanced entry stops the file | Automated control report |
| Bank and account reconciliation | Missing entries force later corrections | Reconciliation screen or RPA |
| Seal or e-signature validity | An expired seal delays the berat | Calendar reminder |
| Berat upload date | Statutory deadline | Team dashboard |
Most of these checks are simply the finance-team version of a sound data governance framework: who owns each field, and where an error is caught, is decided in advance.
Comparison: ERP module or separate e-Ledger provider?
Both routes can be fully compliant. The difference lies in data flow and accountability.
| Criterion | ERP's own e-Ledger module | Separate e-Ledger provider |
|---|---|---|
| Data transfer | Same database, no transfer | File or API transfer needed |
| Troubleshooting | Fix the entry at source | Errors traced across two systems |
| Multi-entity groups | Depends on ERP company structure | Depends on provider support |
| Changing ERP | e-Ledger changes with it | e-Ledger continues regardless |
| Storage | Own infrastructure or ERP cloud | Usually on the provider's side |
The right answer depends on how mature your ERP is. If you have not yet settled whether an ERP fits your business, start by checking whether day-to-day bookkeeping and the general ledger can live in one place. The lessons in our piece on why ERP projects fail apply here too: picking software before the process is clear moves the problem rather than solving it.
How we handle this at Digital Bridge
Digital Bridge is not an e-Ledger provider. We build the data flow between your ERP, your day-to-day bookkeeping and the e-Ledger software you choose. Every engagement starts with discovery and requirements analysis: together with your accountant, we map the last few closes, the manual hand-offs and where people wait on each other. This can sit inside a wider digital transformation consultancy roadmap.
We then pilot the flow that produces the most errors, often incoming invoices or bank movements into the general ledger. On the ERP side we set up mandatory fields, period locks and chart-of-accounts mapping, and we connect your existing ERP to the e-Ledger software through API integration.
Finally, we move the pre-close checks onto a BI dashboard showing numbering gaps, missing document types, reconciliation differences and the berat calendar on one screen, so the team sees problems before any file is generated. We frame this within a digital transformation roadmap, using a clear method for deciding which processes to automate first.
Where an external accounting firm is involved, document traffic matters as well; our guide to accounting firm document management covers how receipts and statements reach the bookkeeper in order. For more guides on Turkey's e-transformation, see our digital transformation topic page.
Next step
If you have just moved to the e-Ledger, or you fix the same errors every month, let us review your last three closes together. We will show which steps are manual, which checks can be automated and how to strengthen the bridge between your ERP and your e-Ledger software. Get in touch through our contact page.