The customer says nothing arrived. Before you resend anything: look up what Zirko knows about the sending. On the document you find the Sending history — one status per attempt, and the status decides what to do.
Read first: the status
| Status | What it means |
|---|---|
| Not sent | Nothing has left Zirko. |
| Being sent | Sending was requested and is still on its way. |
| Sent | The sending service accepted the email. |
| Delivered | The recipient's mailbox accepted it. |
| Undeliverable | The mailbox rejected it — with a reason. |
| Sending failed | The email never left Zirko. |
The latest attempt counts. Sending again starts the delivery process afresh; the old reason stays with the old attempt in the history. If you send a draft that has not been finalized yet, Zirko files away the version that was sent at that point; for a failed attempt you find it via “View the version of this attempt” in the sending history.
If it says "Undeliverable"
Zirko shows the reason the remote mailbox reported — usually a misspelled address or a full mailbox. Check the email address on the customer, correct it and send again.
If it says "Sending failed"
The email never got going, and Zirko names the reason — for example that email sending is not fully set up yet. Fix the cause and send again. If an attempt stays on "Being sent" for a long time, Zirko eventually marks it as failed itself — so you are not waiting for a delivery that was never under way.
If it says "Delivered" — and the customer finds nothing
Delivered means: the mailbox accepted the email. Whether anyone read it, nobody knows — there is no read receipt. The usual place is the spam folder: an invoice from an unfamiliar-looking sender address lands there first. Ask the customer to search for the sender address — it appears in the sending dialog as Sent via …. The lasting fix is your own, connected mailbox; how that works is under Setting up email sending.
If the recipient is a public authority
Authority mailboxes silently reject emails that fail the sender check — you then see an invoice that looks sent and never arrived. For authorities, email is often not the intended route at all: where the file really belongs (portal, Peppol) is under How the authority receives your invoice.
If the recipient wanted an e-invoice and got a PDF
Do not cancel anything. The invoice is correct in substance, it is just in the wrong place — submit the same invoice via the required route. The case is covered in detail under Canceling or reducing an invoice. So it does not happen again: the sending dialog tells you before sending when an e-invoice would be expected and none is attached.
What does not work today
- Zirko does not deliver e-invoices itself. The file is created; the way to the recipient (Peppol access point, authority portal) is yours.
- No read receipts. "Delivered" is the last information there is.