Practical procurement guide: one service can cover both directions; this is not a recommendation to buy two.
Before asking a company to choose its digital postman, we should explain what it is choosing. A receiving address, an outgoing connection, an accounting application and a document archive are not interchangeable things. They can sit inside one product, but the product label does not tell us how responsibilities are divided.
The practical question is not whether a company needs “one contract” or “many contracts” in the abstract. It is whether the smallest workable arrangement covers both directions, identifies the responsible parties and lets the company retrieve its records without buying unnecessary complexity.
The official distinction between receiving and sending
The Financial Directorate’s eFaktúra FAQ, in the file dated 15 September 2026, addresses multiple postmen directly. In Part I, example 36, it says that for a given ParticipantID a business can have only one registered digital postman for receiving documents, recorded in the Service Metadata Publisher, or SMP.6 In plain language, this is the directory information used to identify the receiving route.
The same answer says a business can contract several digital postmen for sending; selection then depends on accounting-system configuration and the contractual relationships, while authentication and technical connection are handled at each provider’s level.6 These two sentences should appear together in every introductory explanation. “One receiving provider” is not a prohibition on multiple outgoing arrangements. “Multiple sending providers” is not a requirement to buy them.
Nor does the guidance require a separate provider for each direction. The Financial Administration describes delivery services that support both sending and receiving through accounting software, web applications or mobile applications.2 For a straightforward business, one service covering both can therefore be the sensible starting point, subject to checking the actual product and terms.
A network role is not a contract count
The official eFaktúra page also describes intermediaries that resell certified providers’ services in their own name.2 This means a familiar accounting supplier can be the visible commercial relationship while another organisation operates the certified connection. Conversely, a company can buy software and delivery separately.
Neither arrangement is inherently better. Bundling can simplify support and avoid repeated configuration. Separation can make it easier to replace a transport provider without changing bookkeeping software. The answer depends on actual interfaces, prices, exit conditions and who accepts responsibility when the connection fails.
A useful purchasing document would name the business, the application supplier, the certified delivery provider and any reseller. Beside each name, it would state what is delivered, which agreement governs it and which support desk receives the first call. The purpose is not to force every participant into a direct contract with the customer. It is to prevent hidden dependencies from becoming a surprise during an incident.
A hypothetical consultancy with two invoicing systems
Imagine a hypothetical consultancy that has grown by acquiring a small training business. Both activities belong to the same legal entity, but consulting invoices are created in an accounting package and course invoices in a booking application. Its accountant wants all incoming supplier invoices in one place.
The receiving arrangement should follow the published rule for the entity’s ParticipantID: one registered receiving digital postman.6 Internally, the company can then design how authorised staff and its accountant see those documents. The directory’s receiving destination should not be confused with the number of people who need access inside the business.
For outgoing documents, the company might use a single provider from both applications. Alternatively, each application might already integrate with a different sending provider. The FAQ allows multiple outgoing providers, but the company still has to configure and contract those connections correctly.6
The second option is not automatically wasteful. Replacing a booking application solely to reduce the number of delivery connections might cost more than keeping a well-controlled arrangement. Equally, adopting every application’s default connection without a common inventory could produce duplicate charges and confused support. This hypothetical example argues for mapping the flows, not for a universal supplier count.
Four questions before buying another service
First, where is the invoice created? The business needs to know whether its application produces the required structured document itself or relies on another service for conversion. A readable PDF is not a substitute for checking that structured data exists: the official guidance defines the electronic invoice as a structured document that supports automated processing.6
Second, where is the incoming invoice first available to the business? There is a difference between a document arriving at the provider and appearing in an employee’s work queue. Ask how that transfer works, who notices a failure and how the company can retrieve the document if automatic import stops. Import or an accountant reading the invoice does not by itself determine the start of a legal deadline; confirm the triggering event for each applicable duty separately.
Third, what evidence is returned? A useful service should label the stages it can actually confirm. The company should not mistake transport success for approval of the supplier’s claim. The FAQ explicitly says delivery is not substantive acceptance by the recipient.6 Payment approval still needs the company’s own checks.
Fourth, what remains available after termination? Ask separately about invoice files, delivery evidence, attachments, application notes and access for the accountant. Do not assume that an invoice archive is included merely because the provider offers transmission. The contract should distinguish the transport service from any longer-term storage product.
Receiving obligations are wider than issuing obligations
A company should not decide it needs no receiving arrangement simply because it does not issue invoices under the same mandatory rules. The FAQ distinguishes the position of non-VAT taxpayers: its example about a landlord who is not a VAT payer says that person need not issue electronic invoices under that obligation, but must be able to receive them when a VAT payer is required to issue one for the relevant domestic supply.6
That distinction makes the simplicity of receiving especially important. A low-volume recipient should not need to understand an entire enterprise integration market merely to obtain an incoming invoice. A basic mailbox-style product may be appropriate, provided its access, retrieval and export arrangements are clear.
There is a further nuance. The FAQ permits alternative delivery of a compliant electronic invoice with the recipient’s consent in the circumstances it describes.6 This should not be read as permission to ignore the separately stated capability requirements. Businesses need advice based on their transactions, not an oversimplified claim that one technical route covers every legal situation.
Delivery and tax reporting need separate ownership
OpenPeppol describes business-document exchange and work on reporting consumption-tax data to tax administrations as distinct areas.4 A business should preserve that distinction in its own operating model, even when its chosen provider performs both tasks automatically.
If two applications send through different providers, each flow needs an identified reporting responsibility where reporting is required. The accountant should know which status belongs to delivery and which belongs to the tax-facing process. A supplier should demonstrate this with a failed submission as well as a successful one.
This is a proposed procurement test, not a claim that any named provider currently duplicates or loses reports. The point is that a contract count tells us little about whether the process is controlled. One opaque bundle can be harder to manage than two clearly documented services, but splitting services also consumes customer coordination time. Require a single support contact to manage an incident through to an explained outcome, including subcontractor coordination; that commitment is distinct from final liability for damage.
The case for keeping everything together
The strongest counterargument to separating functions is straightforward: small businesses do not want to act as systems integrators. A single supplier, single interface and single support route may reduce mistakes. That is a real benefit and can justify a bundled price.
My response is not to force unbundling. It is to demand transparency and an exit path within the bundle. The customer should be able to understand what is included and obtain its documents in usable form. Buying convenience should not require giving up the ability to make a different choice later.
A future public baseline could make a simple receiving and sending route available without a separately negotiated commercial service. That remains a policy proposal, not an existing alternative on which businesses should base today’s compliance preparation. It also would not eliminate the need for optional integrations or internal responsibility.
Start with a map, not another subscription
Before signing, ask the service to supply a standard one-page map of both directions, rather than making a microbusiness its own systems integrator. Identify the legal entity and ParticipantID, the receiving provider, each sending application, the certified operators, the relevant reporting flows and the archive. Then mark who is accountable at every handover.
Ask the proposed supplier to demonstrate a received invoice, an outgoing invoice, a failed transfer and an export. Include the accountant in the exercise. Add services only where that map exposes a genuine need.
The objective is not the smallest number of logos. It is the smallest understandable arrangement that works, can be supported and can be changed. That is how standardised invoicing becomes simpler rather than merely more connected.
Sources
[2] Financial Administration: eFaktúra guidance
[4] OpenPeppol: Communities and Work Groups
[6] Financial Directorate: eFaktúra FAQ, file dated 15 September 2026