How it works
From your ledger to a validated file
Mandatory from 2026, phased by company size. We turn your accounting data into a validated, submission-ready file - with the controls a finance team expects.
Filed monthly by the 14th. A six-month grace period waives early penalties. Confirm your exact phase with the NRA.
Records pulled straight from your accounting system.
Mapped to the official schema and checked against every NRA rule.
Balances cross-checked so the file ties out, with an exception report.
Compliant XML, ready to file, logged with a full audit trail.
SAF-T is not one report. It is your ledger, your master data and your source documents restated in a fixed structure, which is why it exposes problems no monthly close ever surfaced.
Chart of accounts, customers, suppliers, tax codes, units of measure and products. Most first-run failures start here rather than in the transactions.
Every journal for the period, carrying the account, date, document reference and both legs of the entry. It has to agree to your trial balance exactly.
Invoices, credit notes and debit notes at line level, each tied back to a counterparty record and to a tax code the authority recognises.
Settlements matched to documents, the fixed-asset register with its depreciation, and movements of goods. These follow different cycles from the monthly ledger file.
The pattern repeats across every jurisdiction that has introduced SAF-T. The file is refused for reasons that have nothing to do with the XML.
A chart of accounts that grew organically over fifteen years rarely maps cleanly onto a standard taxonomy. Every account left unmapped is a rejection, and the ones that map badly are worse - they pass, and misstate.
Customer and supplier records missing a valid tax or VAT number, or carrying one typed as free text. Common in ledgers where a one-off counterparty was never set up properly.
Each VAT treatment in your system has to resolve to a recognised code, and the totals have to agree with the VAT returns you have already submitted. Where they disagree, the SAF-T file is the version that invites the question.
Ledger entries that do not sum back to the trial balance. Usually period cut-off, adjustments posted outside the system, or a consolidation entry that never existed as a journal in the first place.
Credit notes with no reference to the original invoice, document numbers duplicated across branches, or numbering that resets at the start of each year.
Cyrillic exported in the wrong encoding, dates in local format, decimal separators inherited from a regional setting. Trivial to correct, and they still stop the submission.
None of these are XML problems. They are data problems that stayed invisible until something forced every record through a schema. That is the real work, and it is why starting in the month your phase begins is starting too late.
No. SAF-T is a reporting obligation, not a systems mandate. If the data sits in your system it can be extracted and mapped. Replacing the system usually costs more and introduces its own compliance risk at exactly the wrong moment.
Many vendors will produce a file. Whether it passes depends on your data, not their exporter. The mapping and the master data are yours either way, and so is the liability.
Extraction is a matter of days. The account mapping and master-data cleanup are the real work, and they scale with how long the ledger has been running. A company with twenty years of history has more to do than one incorporated last year.
That is the case it was built for. One pipeline, one mapping held per client, the same validation applied to all of them, and an exception report that tells you which client needs attention this month.
A rejected file is not a filed file, and the clock does not stop while you correct it. Penalties sit under the Tax and Social Insurance Procedure Code - confirm your specific exposure with the NRA or your tax adviser.
Yes, and you should. We build and run the extraction, mapping and validation layer. Your accountant keeps the judgement calls, and gets a file that reconciles before it reaches them.
Not one SAF-T - dozens a month, each from a different system. One pipeline every client runs down the same way, so a new deadline is a routine, not a fire drill.
The same monthly cycle for every employer you serve. Payroll runs flow into the accounting and SAF-T layer - contributions, postings, reconciliations - handled automatically.
SAF-T rolls out in phases by revenue or tax-paid threshold: the largest enterprises (revenue over BGN 300M, or BGN 3.5M+ paid to the NRA) from 2026, large/medium/small firms at the same thresholds from 2027, revenue over BGN 15M or BGN 1.5M+ to the NRA from 2028, all large/medium/small firms from 2029, and everyone else including micro-entities from 2030. Filing is monthly by the 14th, with a six-month grace period waiving early penalties.
SAF-T is not one report - it restates your master data (chart of accounts, customers, suppliers, tax codes, products), every general ledger entry for the period, sales and purchase documents at line level, and payments, fixed assets and stock movements, all in one fixed structure.
The most common causes have nothing to do with the XML itself: chart-of-accounts entries that do not map to the standard taxonomy, counterparty records missing a valid tax or VAT number, tax codes that will not reconcile against VAT returns already submitted, and ledger entries that do not sum back to the trial balance.
We extract records straight from your accounting system, map and validate them against the official schema and every NRA rule, cross-check balances so the file ties out with an exception report, and submit compliant, submission-ready XML with a full audit trail.
Tell us your accounting system and we will tell you what SAF-T takes - and what it costs.