e-Ledger (e-Defter)
Produce journal and general ledger in e-Ledger format from SAP; create certificates, upload to GİB and keep the secondary copy.
What problem does it solve?
The e-Ledger obligation requires the journal and general ledger to be produced monthly in GİB's XBRL-based format, certificates to be time-stamped, signed and uploaded to GİB, and secondary copies of ledgers and certificates to be retained. Missing the calendar triggers penalties directly.
How does the solution work?
The solution generates the journal and general ledger in parts from SAP FI documents, runs GİB schema checks before upload, creates and signs the certificates and submits them to GİB. Ledgers and certificates are archived automatically to meet the secondary retention requirement, and a re-generation step is defined for closing entries and corrections.
What changes in practice?
e-Ledger preparation becomes part of the close calendar rather than a separate project. Schema errors are caught before they reach GİB, and the secondary-copy obligation is met by itself.
Benefits
- The journal and general ledger are produced from SAP FI documents
- Schema checks run before upload, so errors are seen before anything goes to GİB
- e-Ledger preparation becomes a step in the close calendar
Where it sits in SAP
Integrated with SAP FI; covers periodic production of the journal and general ledger in the GİB format, creating and signing the certificates, and keeping the ledgers and certificates. It runs per company code.
Who it is for: Finance Manager, General Accounting, Period-Close Team
Frequently asked questions
Can the e-Ledger be regenerated when a correction is needed after close, and what can be done once the certificate is uploaded?
Before the certificate is uploaded to GİB, the ledger can be regenerated as often as needed; the solution includes a defined regeneration step for this and keeps earlier versions. Once the certificate has been uploaded, that period's ledger cannot be changed, and corrections are recorded in the following period as regulation prescribes. For this reason, e-Ledger generation is positioned in the close calendar after all closing entries and allocations are complete.
How is the e-Ledger produced for companies with several company codes or a branch structure?
The e-Ledger is produced per taxpayer, that is per company code, and the solution can process company codes individually or in bulk. Companies that choose to keep ledgers per branch can structure the parts by branch. Each company code has its own signing certificate, period structure and archive location, and the status of every company's period is visible from a single monitoring screen.
How do splitting and GİB schema checks work at high document volumes, and what is needed for signing?
The ledger is generated in parts according to GİB's file size limits, with the number of parts and the limit managed through system parameters. Each part is run through GİB schema and content checks before upload, and no upload takes place until failing parts are corrected. Signing requires a financial seal or e-signature certificate and a time-stamp service; these are obtained in the company's name and configured in the solution.