Bulgaria SAF-T Requirements: Deadlines and Data Readiness

Bulgaria SAF-T requirements start affecting the first in-scope large enterprises from 1 January 2026, then expand in phases until all VAT-registered enterprises are covered by 2030. For teams planning around Bulgaria SAF-T 2026, this is not just another deadline notice. Businesses need to prepare monthly SAF-T data for accounting entries, sales and purchase invoice registers, and payments, annual fixed-asset reporting, and inventory data on request. Current NRA materials also point to a special introductory rule for first-time filers: when the obligation first arises, the first six months are handled differently, followed by a further correction window.

That combination matters because Bulgaria SAF-T is really a data-readiness project disguised as a compliance requirement. A business can know its rollout date and still be unprepared if invoice records are inconsistent, ledger mappings are incomplete, or the link back to source documents is weak. Finance teams need to know not only when reporting starts, but also what the filing structure expects and which controls must be working before the first mandatory period arrives.

If you are responsible for Bulgarian compliance, the core questions are straightforward:

• Are you in one of the earlier rollout waves?
• Which datasets must be available every month, every year, or only on request?
• How does the introductory six-month rule affect first filings?
• Can your systems produce records that stand up to review, reconciliation, and audit traceability?

This Bulgaria SAF-T guide answers those questions in operational terms. Instead of treating SAF-T as a generic tax update, it focuses on what the National Revenue Agency (NRA) rollout means for invoice capture, ledger quality, mapping logic, and source-document traceability inside real finance workflows.

---

Who Enters Scope in Each Rollout Phase

The rollout is phased, so the first question is whether your business enters the obligation in the early waves or has more time to prepare. This Bulgaria SAF-T rollout timeline is the framework finance teams should use for planning.

• From 1 January 2026: the first in-scope large enterprises
• From 1 January 2027: the next large-enterprise wave
• From 1 January 2028: medium enterprises
• From 1 January 2030: small enterprises and the full expansion to VAT-registered enterprises

For the early phase, the key trigger is not just company size in a general sense. It is tied to financial thresholds. As PwC Bulgaria's SAF-T rollout overview explains, Bulgaria's SAF-T rollout becomes mandatory in waves starting in 2026 for large enterprises with annual net revenue above BGN 300 million or annual net tax and social security liabilities above BGN 3.5 million, and expands to all VAT-registered enterprises by 2030.

That threshold test matters for multinational groups, Bulgarian subsidiaries, and finance teams supporting entities with changing revenue profiles. A business may assume it has time because it is not thinking about SAF-T as a near-term project, then discover it falls into an earlier phase because of its revenue or liability position. That is why rollout planning should start with a scope assessment, not with schema mapping.

It also helps to separate formal scope from practical readiness. Knowing that your entity enters in 2027 or 2028 does not mean you can wait until then to begin. If invoice data is spread across multiple systems, tax codes are applied inconsistently, or ledger structures have evolved without clean documentation, the real implementation work starts well before the formal phase date.

One more caution: some English summaries still reflect the initial announcement cycle rather than the later NRA implementation materials. Use the phase dates as your high-level guide, but verify the live filing mechanics and current instructions against the NRA's latest published guidance before you lock your timetable.

---

What Bulgaria SAF-T Filings Actually Contain

When people search for Bulgaria SAF-T monthly annual on-request filing rules, they are usually trying to answer a deeper question: what has to exist inside the file, and where does that data come from?

For Bulgaria SAF-T, the reporting structure is broader than a simple invoice list:

• Monthly reporting centers on accounting entries, sales and purchase invoice registers, and payments
• Annual reporting covers the fixed asset register
• On-request reporting can extend to inventory or stock data when the tax authority asks for it

This is why SAF-T readiness reaches beyond accounts payable or output VAT reporting. The file depends on a connected data model across your general ledger entries, invoice registers, payment records, and asset data. If one part is weak, the problem does not stay isolated. A missing supplier identifier, an inconsistent tax code, or a payment that cannot be tied back to the right invoice can create friction well beyond one table in the SAF-T XML schema.

The schema matters because it forces teams to think in mapped fields, not just exported reports. If your ERP labels the same concept differently across business units, or if different source systems store tax-relevant fields in inconsistent ways, the reporting package becomes a transformation exercise before it becomes a filing exercise. That is why controllers should review field definitions, account mappings, and export logic early.

It can help to compare Bulgaria's model with other SAF-T implementations in the region. For example, our guide to Romania SAF-T D406 filing and data-readiness steps shows the same broader pattern: the challenge is not only generating a file, but producing dependable invoice, ledger, and supporting-record data behind it.

For Bulgarian teams, the practical takeaway is simple. Treat each SAF-T package as evidence of how well your finance data holds together. If monthly invoice and payment data are incomplete, annual fixed-asset records are outdated, or inventory data is not reliable enough to supply on request, the filing structure will expose those gaps quickly.

---

The Introductory Six-Month Rule and Filing Mechanics

One of the most important details in the newer NRA materials is the introductory rule for first-time filers. The practical meaning of Bulgaria SAF-T first six reports correction guidance is that when the SAF-T obligation first arises, taxpayers do not submit SAF-T for the first six months, and then a further six-month period is available for corrections. That point is easy to miss if you rely only on older advisory summaries.

The rule changes the shape of the first year, but it should not be misunderstood as a delay tactic. It does not remove the need to prepare clean data from day one. If anything, it raises the value of early internal testing. Teams still need to know whether invoices, payments, ledger entries, and master data can be mapped correctly, because the correction window only helps if the underlying records are already recoverable and traceable.

This is also where the Bulgaria NRA SAF-T submission service becomes relevant. Practical readiness is not only about understanding the legal structure. It is about knowing how the electronic filing process works in real life, which service is used for submission, and how the NRA's live calendar and implementation guidance frame the first reporting cycles. Finance teams should check the live submission environment and current instructions before go-live rather than assuming that a March 2025 tax alert still reflects the operating reality in 2026.

The most common implementation mistake is treating filing mechanics as a late-stage task. A company spends months discussing scope, then leaves the actual submission workflow, correction handling, and evidence pack too close to the first deadline. That creates avoidable risk, especially when multiple systems feed the file.

If that pattern sounds familiar, look at how other countries have handled the same problem. Our article on Norway SAF-T mapping and audit-file preparation is useful because it shows that the real work often sits in mapping discipline and audit-file preparation, not in the act of uploading a file.

---

The Data Readiness Work Bulgaria SAF-T Exposes

Bulgaria SAF-T becomes manageable when finance teams stop viewing it as an XML project and start treating it as a control project. Before the first mandatory period, you need dependable source records for:

• invoice headers and supplier or customer identifiers
• tax codes and taxable amounts
• payment records and settlement references
• general-ledger postings
• fixed-asset data
• stock or inventory records where relevant

In practice, the weak points are rarely exotic. They are usually everyday process failures that have been tolerated for years: one system stores supplier names differently from another, a tax code is used inconsistently across business units, ledger entries cannot be traced back to the originating document, or document retention is strong for some teams and poor for others.

That is why ERP field mapping deserves as much attention as deadlines. If your chart of accounts, tax logic, and document classifications do not align cleanly, the SAF-T file will reflect those inconsistencies. The same applies to audit trail and source-document traceability. If you cannot move from the reported data back to the supporting invoice or payment record with confidence, you are carrying compliance risk even if the export technically completes.

For teams working through that cleanup, invoice data extraction workflows for SAF-T-ready records can help as a practical part of the preparation stack. Invoice Data Extraction is designed to turn mixed financial documents, including PDFs, JPGs, and PNGs, into structured Excel, CSV, or JSON outputs based on user instructions. It can also include source-file and page references in each row, which is useful when controllers need to review extracted invoice and payment data before mapping it into reporting structures. That does not replace ERP design or tax judgment, but it can reduce manual rekeying and make reconciliation work more reviewable.

The same operational lesson appears in nearby regimes. Our guide to Lithuania's invoice-register reporting deadlines and workflow controls shows how quickly filing obligations become data-quality problems when invoice registers, ledger logic, and retention controls are not aligned.

The right way to prepare is to test the full chain: extraction, field validation, mapping, reconciliation, and exception handling. If you leave that until just before filing, you are not really testing readiness. You are discovering gaps under deadline pressure.

---

A Practical Bulgaria SAF-T Preparation Checklist

Once you know your rollout phase, turn Bulgaria SAF-T into a defined workstream with clear owners. A useful preparation sequence looks like this:

1. Confirm scope and timing. Establish which rollout wave applies to the entity, who owns the interpretation, and which NRA materials you will treat as the current source for filing mechanics.
2. Define the reporting datasets. Separate the monthly package from the annual fixed asset register and the inventory data that may be requested on demand. Each dataset should have a named system owner.
3. Map fields from source systems into the SAF-T structure. Review chart-of-accounts logic, tax-code alignment, document types, and master-data consistency. This is where a standard audit file for tax Bulgaria workstream either gains discipline or drifts into rework.
4. Test the evidence chain. Make sure reported values can be traced back to invoices, payments, ledger entries, asset records, and supporting documents without manual detective work.
5. Run trial outputs before the first obligation bites. Use sample periods to check that data can be extracted, transformed, reviewed, corrected, and retained in a way your finance team can repeat.
6. Document the correction workflow. The introductory six-month mechanism helps only if your team knows how exceptions will be found, fixed, approved, and evidenced during the following period.
7. Set ongoing controls. Assign responsibility for monitoring filing windows, data-quality issues, retention rules, and changes to mappings or source systems.

This checklist is what turns Bulgaria SAF-T filing deadlines into a manageable implementation plan. The real danger is discovering too late that invoice data, payment records, general-ledger postings, the fixed asset register, or inventory data on request cannot be reconciled into an audit-ready file.

If you frame the project that way, the priority becomes clearer. Start with scope, build the mapping layer, test traceability, and only then worry about whether the final file can be transmitted. That sequence gives finance teams a better chance of meeting the reporting obligation without scrambling to rebuild the source data underneath it.