The 2026 SEF ecosystem: one portal, four lifecycles

In April 2026 the fiscal receipt gained a link to the e-Invoicing system. From 1 July the Central Invoice Registry identifier arrives derived from SEF rather than from a portal of its own. The electronic delivery note was already in force, and VAT records no longer live in a spreadsheet — they are EEO and EPP entries inside the very system the invoice travels through. From the taxpayer's chair this is one thing, called SEF. To the system feeding it, these are four services sharing a name, a portal and a certificate. Nothing more.

What actually merged

Identity, transport and control merged: one legal-entity account, one API key, one portal, and one point where the state compares what the invoice says with what the VAT record and the delivery note say. A disagreement between the sales ledger and the POPDV overview used to be an internal problem surfacing in an audit once every few years. It is now machine-comparable, within days, on the state's side of the wire.

What did not merge is the business event. An invoice arises when goods ship or a service is performed. The VAT record arises when the tax period closes. The delivery note arises before the truck moves. The registry entry lives until the receivable is settled, which may be ninety days later. Four triggers, four clocks, none ticking together.

No row shares a trigger, a deadline or a terminal state with any other. They share transport — that is the whole overlap.

The illusion of a single flow

On the operator's screen it genuinely looks like one flow, and for good reason.

• One legal-entity account and one certificate open every service.
• Invoice, VAT record and delivery note reference each other through the same identifiers.
• Errors from any of them come back through the same portal, in similar language.
• The tax authority reads them together — and asks why they disagree.

From that picture to “let us build one module that does SEF” takes a single meeting. The conclusion is wrong, and the bill arrives the first time something changes — which here is every year.

The deadlines do not line up

EEO is filed within ten days of the tax period closing. EPP has its own deadline, the 12th of the following month, and its own rules about the data as at the 10th. An inbound invoice must be accepted or rejected within fifteen days of receipt — a clock started by somebody else's action, not by your month end. The delivery note has no deadline in days at all; its deadline is physical: it must exist before the goods move. Hold those four calendars in one scheduler behind one “SEF sync” and you have invented a calendar found in no statute.

The lifecycles do not line up

A delivery note can be confirmed while the invoice raised against it is rejected. An invoice can be accepted while the record for its period is still open. A receivable can sit in the registry, partly settled by a payment that arrived with the wrong model 97 reference — long after the invoice and the record reached their terminal states. Hold those statuses in one state machine because “it is all SEF” and you have manufactured a state none of the four services has, then must translate it in both directions. Translation without an original is where a system starts lying without intending to.

Coupled in the domain: the link that must exist

The opposite mistake costs the same. Treat the four services as four unrelated integration projects and the link between them lands on a person: someone copies the delivery-note number onto the invoice, someone hunts for the identifier in the registry portal, someone reconciles the record against the ledger at month end. Every act of re-keying is where two records drift apart, months before anyone notices. In the domain those four flows are one graph, and that link is a business fact rather than an integration concern — it belongs in the model however many services the state operates.

1. The sales order reserves stock; for date-controlled goods the LOT is chosen by FEFO, not by what the picker can reach first.
2. The shipment relieves stock and produces a delivery note with real quantities, lots, carrier and vehicle.
3. The e-delivery note is derived from that document before the goods move — not copied, never typed twice.
4. The invoice comes from the same shipment, so the quantity billed and the quantity that physically left cannot diverge.
5. The VAT engine sets the treatment on the line under the mapping in force for that tax period, and that treatment feeds both the posting and the EEO record.
6. The receivable enters the registry; settlement matches on the model 97 reference, and a customer paying via the invoice's IPS QR code hits exactly that reference.

When all of that comes out of one graph, the control report reconciling the POPDV overview against the filed records stops being a monthly chore and becomes a check that must return empty. If it does not, the defect is in the model — and defects in a model can be found. Defects in re-keying are only hunted.

Decoupled at the integration: what “its own adapter” means

An adapter is not an API client. The client is its smallest and least interesting part. The adapter is everything else required so a system you do not control can be asked the same question twice without consequence.

1. 1

   Its own state machine

   The statuses the service actually has, not the ones we wish it had. Translation into a domain status is explicit and lives in one place.

2. 2

   An idempotency key

   Sends repeat: timeouts, restarts, an operator clicking twice. Without a key the service recognises, a repeat is not a no-op — it is a duplicate invoice.

3. 3

   Its own watermark

   How far this adapter has read. Share one across four services and a stall on any of them moves the position for all four.

4. 4

   The rule version in the trail

   Every document carries the rule-pack version it was built under and its legal source. Asked two years later why it looks that way, the system answers with a record.

5. 5

   Its own retry policy

   A fifteen-day deadline and a “before the truck moves” deadline do not tolerate the same give-up strategy. They cannot share a backoff curve or a dead-letter queue.

Five things, four times over. That is more code than one module with one scheduler, and decoupling is paid for up front. In return, when SEF changes a rule in April, one adapter changes and the regression runs against one suite — while the delivery note flow never learns anything happened.

Where the boundary genuinely leaks

Decoupling is not a religion. There are points where these flows genuinely touch, and they deserve naming rather than wishing away.

• The fiscal receipt to SEF link: retail turnover and e-invoicing are no longer separate worlds, so the same turnover must not enter the record twice.
• A shortfall found at stocktake becomes an internal VAT calculation and ends up in the record — born in inventory, landing in the tax flow.
• Imports: the source document is not the delivery note but the customs declaration (JCI). Cost is assembled from customs value, duties and landed costs, and import VAT is not treated like a domestic purchase.
• Excise goods run a distinct e-delivery-note flow, with stricter rules.
• Advance invoices: the liability arises on payment and the final invoice must absorb it — one event touching invoice, record and receivable.

Each is a further argument for keeping the link in the domain, where it is a rule over business objects, rather than in an adapter, where it becomes a conditional nobody can find.

Where NG One draws the line

NG One draws it exactly here. Every service has its own adapter, with its own lifecycle, its own sync statuses and its own watermark: the SEF channel sends outbound invoices and pulls inbound ones, EEO and EPP keep their calendar, the delivery note keeps its own, the registry keeps its own. The link between invoice, record, delivery note and registry lives in none of them — it lives in the domain, as a graph. No deadline is hard-coded: all of them come from a versioned compliance rule pack of time-versioned statutory parameters that shift for non-working days, so a change in the law lands as a new rule version rather than a code change. The ordering follows from the same cut: the UBL 2.1 document and the POPDV and PP PDV XML are produced by the system itself, out of the same graph that produces the posting — not by an adapter. The file is the domain's job; the connection is integration's job. The reverse does not hold — an adapter that rapidly transmits a badly modelled figure only delivers the error faster.