Answers to the questions that come up most often in a Slovakia integration, from duplicate notifications to Push delivery.

Why do I receive two status notifications for each invoice?

Slovakia uses a 5-corner PEPPOL model. After you submit an invoice, two independent events happen:

1. Network delivery to the buyer's Access Point (confirmed by SCICloudStatusCode 216 — Message Level Response).

2. Tax Data Document (TDD) reporting to the Slovak Financial Administration (confirmed by SCICloudStatusCode 200 — Extended Message Level Response).

Each event generates its own notification. You poll for both. Track them separately — delivery success doesn't guarantee TDD reporting success.

When is my invoice submission complete?

Your submission is complete when you receive SCICloudStatusCode 209 (Completed). This is the only terminal success state. It confirms both delivery (MLR) and TDD reporting (eMLR) resolved successfully. Don't treat 216 alone as final.

Do I need to do anything to trigger TDD reporting?

No. Unimaze, Sovos's network partner, generates the Tax Data Document and reports it to the Slovak FA automatically after delivery. You don't trigger it, and you don't need to manage it directly. You need to poll for the eMLR notification (status 200) to confirm it succeeded.

What's a Message Level Action (MLA) and do I need to handle it?

No. An MLA is an internal network trigger that Unimaze uses to initiate TDD reporting. The Sovos platform marks MLAs as delivered automatically. They don't surface as a notification you need to acknowledge or act on. If you see a reference to MLAs in platform documentation, you can safely ignore it for integration purposes.

What happens if the buyer isn't registered on the Slovak PEPPOL network?

If the buyer's participant identifier isn't in the Slovak SMP, Sovos can't route the invoice. You'll receive a status notification indicating the recipient wasn't found. There's no confirmed fallback delivery method — email distribution is listed as out of scope for this release.

Before submitting to a new buyer, ask them to confirm their PEPPOL participant identifier and that they've registered with a PEPPOL-accredited Access Point in Slovakia.

What should I do if no Invoice Response arrives after delivery?

You don't need one to confirm delivery. SCICloudStatusCode 216 confirms the invoice reached the buyer's Access Point. An Invoice Response from the buyer is not a legal requirement for B2B e-invoicing in Slovakia — not all buyers send them. If you need to follow up, contact the buyer directly.

Why does the outbound product ID use a double underscore?

The outbound product ID is sk_Invoice__1.0 — two underscores between Invoice and 1.0. This is the confirmed value and isn't a typo. Using a single underscore (sk_Invoice_1.0) causes provisioning to fail.

What's the difference between processType=0 and processType=1 in the polling request?

processType=0 retrieves outbound notifications — status updates for invoices you submitted as a supplier. processType=1 retrieves inbound notifications — invoices that arrived for you as a buyer. Use the wrong value and polling returns an empty result without an error.

Can I use Push (Svix) delivery instead of polling?

Push delivery is supported at the platform level, but only polling is configured in the Slovakia source material. Check with your Sovos implementation team whether Push is available for your Slovakia integration in this release.