Belarus Electronic VAT Invoice Guide: ESChF Explained

In Belarus, the electronic VAT invoice, usually called the ESChF, is a VAT-layer document handled through the Electronic VAT Invoice Portal. It does not replace the supplier invoice, contract, delivery document, or other primary accounting document behind the sale. Instead, it sits on top of the commercial record and supports the tax side of the transaction.

That distinction is the starting point for any useful Belarus electronic VAT invoice guide. If your team only stores the supplier invoice and ignores the ESChF, you can miss the document trail that supports input VAT deduction. If you only look at the portal record and fail to match it back to the underlying documents, you create a different control problem: the tax record may no longer reconcile to what was actually supplied, invoiced, delivered, or accepted.

As summarized in B1's 2025 Doing Business in Belarus guide, Belarus electronic VAT invoices must be submitted by all VAT payers, serve as a basis for applying VAT deductions, and are created, issued, received, signed, and stored through the Electronic VAT Invoice Portal. That is why the ESChF matters even when the underlying commercial invoice already exists in your ERP or document archive.

For most finance teams, the practical workflow looks like this:

• the business transaction is documented through the usual commercial and accounting records
• the VAT-layer data is then reflected in the ESChF
• the ESChF is handled through the portal rather than treated as a loose PDF attachment
• the buyer relies on that portal-based record, together with the supporting documents, when defending VAT treatment

The general rule is that the ESChF must be issued by the 10th day of the month following supply. Depending on the transaction, the taxpayer either sends it to the buyer through the portal or uploads it directly to the portal. So the operational question is not just, "Was an invoice raised?" It is, "Was the Belarus electronic VAT invoice created correctly, routed correctly, and matched to the source documents that prove the transaction?"

That is where Belarus differs from the generic "mandatory invoice fields" articles that dominate many VAT searches. The real issue is workflow. Your team is managing a government-portal tax record alongside the commercial document set, and VAT deduction depends on keeping those layers aligned.

When an ESChF must be issued and what triggers it

The ESChF obligation is tied to the VAT side of the transaction, not just to whether your business issued a normal invoice. In practice, the first question is whether a Belarus VAT payer is involved in a taxable transaction that requires an electronic VAT invoice record in the portal. If the answer is yes, your process needs to move beyond document creation and into deadline control.

For many standard B2B transactions, that means the seller creates an ESChF that the buyer can receive through the portal. The commercial invoice still matters for pricing, payment, and contract administration, but it does not replace the Belarus electronic VAT invoice requirements attached to the tax record.

The key timing point is straightforward: as a rule, the ESChF is issued by the 10th day of the month after supply. Teams often trip up here because they anchor their controls to the invoice date shown on the supplier document or to the date goods were paid for internally. The better control is to track the tax-relevant supply event and then monitor whether the ESChF deadline was met.

You should also separate three different questions:

1. Was there a taxable transaction that triggers ESChF handling?
2. Does the buyer need to receive the record through the portal, or is this a case where the taxpayer uploads it directly to the portal?
3. Has the ESChF been created within the normal deadline window, regardless of when the underlying invoice was printed or emailed?

This is especially important for finance teams that operate shared-service or regional review models. A local business user may think "the invoice is done" once the commercial document has been issued, while the tax team still has a Belarus electronic VAT invoice deadline to manage. That gap is where missed deductions and month-end cleanup work usually begin.

Because Belarus workflow can vary by transaction type, it is sensible to validate edge cases against current guidance from the Belarus Ministry of Taxes and Levies or local advisers. But as a day-to-day operating rule, treat the ESChF as its own controlled obligation with its own trigger logic and timing, not as a side note attached to the supplier invoice.

How the ESChF portal workflow works in practice

The Belarus ESChF portal workflow makes more sense when you picture it as a structured tax record moving through a controlled system, not as an email attachment moving between companies.

A practical day-to-day flow usually looks like this:

1. Capture the source-document data. The seller starts from the commercial invoice, contract, delivery evidence, service act, or other transaction documents that describe what actually happened.
2. Prepare the VAT-layer record. The tax-relevant details are mapped into the ESChF structure, including the information needed for portal handling and VAT accounting.
3. Create or upload the structured file. In Belarus, the electronic VAT invoice portal is designed around structured submission rather than casual document exchange, so the XML invoice file and related data model matter.
4. Sign and submit through the portal. A digital signature is part of the workflow because the Electronic VAT Invoice Portal is the formal environment where the ESChF is created, issued, received, and stored.
5. Route the record correctly. For some transactions, the ESChF is sent to the buyer through the portal. In other cases, the taxpayer uploads it directly to the portal to satisfy the tax-control requirement without a buyer-facing exchange in the usual sense.
6. Reconcile status and evidence. Finance teams then confirm that the portal record matches the source documents and that the transaction sits in the right bucket for VAT reporting and deduction review.

That routing point matters more than it first appears. If your process assumes every ESChF behaves like a buyer-delivered invoice, you can mis-handle cases where the portal record exists primarily as a tax administration artifact. If your process assumes everything is portal-only, you can miss buyer-side controls where receipt through the portal affects how the counterparty supports deduction.

This is one reason Belarus is best understood alongside other government-structured models such as Romania's RO e-Factura portal workflow or South Korea's Hometax electronic tax invoice process. The systems differ, but they share a core idea: the tax authority's platform becomes part of the invoice workflow itself.

For controllers and ERP teams, the key lesson is that the Electronic VAT Invoice Portal is not just a filing endpoint. It is part of the operating process. Your internal controls should therefore track source-document capture, XML preparation, signature, submission, portal status, and final reconciliation as one connected chain.

---

What belongs in the ESChF versus the underlying document

Many compliance articles blur the ESChF together with the ordinary invoice. That is exactly the confusion Belarus teams need to avoid.

The underlying document records the business event. Depending on the transaction, that may be a supplier invoice, contract, acceptance act, shipping record, or another primary accounting document that proves what was sold, when, and on what commercial terms. The ESChF, by contrast, records the VAT-layer treatment of that event inside the Belarus electronic system.

That means you should not ask only, "Do we have the invoice?" Ask two separate questions:

• Do we have the commercial and accounting evidence for the transaction?
• Does the ESChF reflect that transaction correctly in the portal?

At a high level, the ESChF will capture the tax-relevant transaction data your VAT process depends on, while the primary accounting document remains the source evidence for the underlying sale, service, adjustment, or receipt. In practice, finance teams usually reconcile items such as counterparties, transaction identifiers, dates, VAT amounts, and the nature of the supply between those two layers.

That does not mean you need a long checklist every time you review an ESChF. It does mean you should expect the VAT-layer record to reflect the core tax facts behind the transaction, such as who the parties are, what supply is being reported, the taxable base, the VAT amount, and any reference points needed to tie corrections or adjustments back to the original event.

This is where Belarus stands apart from systems where a structured e-invoice largely replaces the traditional invoice exchange. In Finland's structured e-invoicing formats and routing model, structured message routing is central to commercial exchange. Belarus still requires you to think carefully about the relationship between the VAT portal record and the underlying document set.

If you treat the ESChF as the only record that matters, you weaken your audit trail because the portal entry still needs support from the real-world transaction documents. If you treat the supplier invoice or service act as enough on its own, you can overlook errors in the electronic VAT invoice record that later affect deduction review. The safer approach is to preserve both layers and build controls that check whether they tell the same story.

That is also why reconciliation work should not stop at file storage. A correctly archived PDF does not prove that the ESChF data, XML structure, and tax amounts were handled correctly in the portal, just as a portal record alone does not prove the commercial event was documented properly.

---

How common Belarus transaction scenarios change the workflow

Once you separate the ESChF from the underlying document, the next step is to understand how the workflow changes by scenario. The rule set becomes easier to manage when you classify transactions by the portal action required and by how strongly the buyer's deduction position depends on that action.

Transaction type	What happens in ESChF	Why it matters
Standard B2B taxable supply	The seller creates the ESChF and, in the ordinary case, routes it through the portal for buyer-side use.	This is the clearest link between the ESChF and input VAT deduction because the buyer expects a usable portal record tied to the underlying invoice and supporting documents.
Taxable B2C or retail activity handled on a summary basis	The taxpayer may reflect the VAT position through period-based or summary portal logic rather than one buyer-specific electronic VAT invoice for each sale.	Teams need controls that tie summary records back to retail evidence, cash-register data, or other source records instead of looking for a one-to-one buyer invoice every time.
Import-related or foreign-supplier / nonresident case	The ESChF handling can differ because the tax event, document source, or counterparty setup is not the same as a domestic seller-to-buyer exchange.	These cases often create confusion over who prepares the tax-layer record, what supporting documents sit underneath it, and how deduction evidence is assembled.
Adjustment, correction, or change in tax treatment	The portal record must reflect the revised VAT position, while the commercial document set may also need credit-note, adjustment, or other supporting evidence.	These cases create the heaviest reconciliation burden because teams must align the corrected ESChF, the original transaction history, and the updated source documents.

The practical lesson is that the control question stays the same in every branch: what evidence supports the transaction, what ESChF action is required, and who will rely on that portal record later?

For a controller, that makes scenario mapping more useful than memorizing isolated rules. B2B flows are deduction-sensitive for the buyer. B2C summary logic changes the matching model. Import or nonresident scenarios can change who creates the tax-layer record and what sits beneath it. Adjustments require a careful link between the original and corrected positions.

If your process map captures those scenario differences upfront, month-end review becomes much cleaner. Instead of treating every record as the same kind of invoice, your team can separate standard buyer-routed ESChF cases from portal-only or exception-driven cases and review each bucket with the right evidence set.

---

Controls that protect VAT deduction and audit readiness

The most common Belarus input VAT deduction ESChF failures are not dramatic legal misunderstandings. They are process failures: the commercial invoice is present but the portal record is late, the ESChF exists but does not reconcile to the source documents, or an adjustment is booked without the tax-layer record being reviewed with the same care.

A workable control framework usually includes the following checks:

• Match the two layers. Confirm that the source documents and the ESChF describe the same transaction, counterparties, dates, and VAT amounts.
• Track the normal deadline. Monitor whether the electronic VAT invoice was handled by the usual 10th-day deadline after supply, rather than assuming the invoice issue date solves everything.
• Classify the scenario correctly. Distinguish buyer-routed cases from portal-only cases, and flag import, nonresident, retail-summary, and adjustment situations for separate review logic.
• Confirm portal completion. Check submission status, signature requirements, and whether the record is actually present in the Electronic VAT Invoice Portal in the form your process expects.
• Retain a full audit trail. Keep the supplier invoice, contract or act, delivery support, correction records, and portal evidence together so a reviewer can follow the transaction from commercial event to VAT deduction claim.

These controls matter because the Belarus Ministry of Taxes and Levies framework is not built around a one-document filing exercise. It is built around consistency between the tax record and the underlying evidence. When that consistency breaks, the finance team spends time proving what should already have been obvious from the files and portal history.

For many organizations, the most useful review question is this: if an auditor or tax reviewer pulled this transaction tomorrow, would they see one coherent story across the commercial documents, the ESChF, and the deduction claim? If the answer is uncertain, the fix is usually not more storage. It is better reconciliation logic, clearer scenario rules, and a tighter month-end check on portal status and supporting evidence.

Belarus VAT compliance works best when you treat the ESChF as a workflow discipline. The commercial invoice starts the story, but the deduction-safe record is the combination of source documents and a correctly handled electronic VAT invoice.