Sending invoices

Each stage is recorded rather than replaced, so an invoice carries its whole history. That matters when something goes wrong: you can see whether it failed on the rules, on the conversion or on delivery, and those are three different problems with three different fixes.

Sent is the milestone that counts for compliance. Delivery to the buyer is a separate question — an invoice to a buyer who is not on the network is still filed, and still reported, even though there is no access point to deliver it to.

An invoice is staged when it needs a field your accounting system does not hold — one you marked as Will be provided at invoice level on PINT Mapping. The invoice is read out of the ERP as normal and then stops here rather than continuing, because the value it needs was never going to arrive from your system.

1. The invoice arrives from the ERP and appears under Staged Invoices.
2. You open it and fill in the values marked as provided at invoice level.
3. You submit it.
4. It rejoins the normal flow — validated, converted, and sent to the Peppol network. Where the entity requires approval, it waits for an Approver first.

Nothing leaves while an invoice is staged, so a field left unfilled is an invoice not filed. Only invoices that genuinely need the field are held, though: a plain domestic tax invoice is not parked waiting for a continuous-supply billing frequency it could never use.

Approval applies to the invoices you send. It is switched on per entity, and while it is on every outgoing invoice waits under Invoices to Approve until a person releases it. With it off — the default — nothing waits: an invoice read out of your system is approved by definition, and the Approval column does not appear at all.

There is no approval step for invoices you receive. A supplier's invoice was filed on the network before it ever reached you; holding it back approves nothing and only keeps your own books out of date, so received invoices go straight to your accounting system.

An Approver can view the invoice, comment on it, approve it or reject it — and can do nothing else on the entity, which is what makes the role safe to give to someone you do not want editing the mapping or the connection. Admins and Editors can approve too. Users and roles sets out who can do what.

A rejection at this stage is a human decision, not a rule failure, and the comment is what tells the person who raised the invoice what to change.

An invoice is checked against the UAE PINT-AE rules before it is put in front of an approver, never after. What waits for you has already been found complete, so approving it releases it — there is no second gate behind the decision where it can still fall over.

When an invoice fails those checks it still appears under Invoices to Approve, because the approver is the person waiting on it. It arrives carrying its errors, listed on the invoice, and Approve is unavailable until they are fixed. Approving would release nothing: the invoice would fail the same way and come straight back.

Reject and comment stay available, because sending it back to whoever raised it is usually the right move. Fix the cause — in your accounting system, or in the field mapping — and the invoice revalidates on its own; once it passes, it can be approved.

When an invoice starts waiting, the people who can release it are emailed. If the entity has someone with the Approverrole, only they are written to — that is what the role is for. If nobody holds it, the request goes to the owner and the admins, who can approve anyway.

The mail goes out after the invoice has been checked, never before, so what it points at is an invoice whose position is already settled. That includes one that failedthe check: it is in the approver's queue, so they are told about it, and the errors are listed on the page when they open it. Approve is unavailable there until they are fixed, but rejecting and commenting are not — sending it back is usually the right move.

The email itself names only your company and carries the link — nothing about the invoice, because a mail sits in an inbox indefinitely and cannot be withdrawn. The page behind the link opens without a login, so an approver who has no account can still act, and it shows the invoice number, the other party, the total and the date, plus any validation errors — enough to decide. The line items, the buyer's TRN and the addresses are not there either: a link can be forwarded, and anything on the page travels with it. To see the whole document, sign in and open Invoices to Approve.

The link is for one invoice and stops working as soon as that invoice is approved or rejected, whoever did it and wherever they did it. If nobody acts, it expires after seven days and the invoice simply stays in Invoices to Approve— an expired link changes nothing about the invoice. Commenting does not use the link up, so an approver can ask a question and come back to decide.

Both routes are the same decision. An invoice approved from the email is approved exactly as one approved on screen: same checks, same record of who decided, same onward journey to the network.

Approving does not start the invoice over. It was validated before you were shown it, and it is the same invoice — so it goes straight to the UBL XML and onto the network. That is why approving is quick, and why the status trail records the earlier check rather than running a second one.

With one exception, and it is the reason the rule is worded this way: if your field mapping or your company details were edited while the invoice was waiting, the earlier check no longer describes the rules that now apply. In that case the invoice is validated again before it is sent, and if it now fails you will see it back under Invoices to Approve with the errors on it.

An invoice already filed will not be filed again under the same number, on the same date, to the same buyer. That is deliberate: a retry, a duplicate webhook and a genuine re-issue look identical from outside, and filing the same invoice twice is worse than filing it once.

To correct something already sent, raise a credit note against it. See Invoice rules.