The posting gate
The document is checked inside the posting that produces it. That is what makes refusing possible, and it is also why the choice deserves a moment.
Most validation happens after the fact: the document is produced, checked, and flagged. That catches problems, and it catches them once the invoice is already posted and the customer is already expecting it.
The posting gate runs earlier. The document is rendered while the posting is still open, and its verdict can stop the posting. That is a genuinely different thing, and it is worth understanding before you switch it on.
What the person posting sees
| Mode | What happens when the document does not pass |
|---|---|
| Off | The document is not checked against the rule set. It is produced and sent, valid or not |
| Warn | The posting completes. The failure is recorded on the message and the queue row, and the document is still sent |
| Block | The posting is refused with the reason in the message bar. Nothing is posted, nothing is sent, and nothing is half done |
One set of checks is not part of this choice. Before the gate runs, the module checks the setup a send cannot happen without: your own identifier and the partner’s, an identifier that is addressable and the right shape, a reporting mapping on the agreement, a certificate that exists and has not expired, and a country on the sender. Any of those missing refuses the posting whatever the mode says, because sending anyway cannot fix them and each one is something a person can correct in a form. The field’s help text says the same: prerequisite checks always block.
In block mode the refusal is a real refusal: the invoice is not posted, the number is not consumed, and the user is looking at the reason. They can fix it and post again.
Why the gate exists at all
Because the alternative is worse. An invoice that posts and is then rejected by the receiver has to be credited and reissued, which means a credit note, a second invoice, a conversation with the customer's accounts payable, and a payment that arrives a month late. Refusing the posting costs someone two minutes.
The economics only work where the rejection is likely and expensive. That is invoices, and mostly public sector invoices, where the rules are published and enforced strictly.
Choosing per agreement
The mode is set per agreement, which means per document type per partner. That is deliberate: the right answer is different for an invoice to a public authority and a despatch advice to a warehouse.
Blocking an invoice posting stops one invoice. Blocking a packing slip posting stops a delivery, and a lorry that is loaded and waiting does not care that the document was malformed. Where a posting is part of a physical process with people standing next to it, warn is usually the honest setting.
What refusing does not do
It does not partially post. It does not leave a queue row behind for someone to clean up. It does not create a message that has to be cancelled. The posting is rolled back, and the state afterwards is the state before, which is the only behaviour that is safe to give to a user who is not going to read the details.
When the check cannot run
A rule set that cannot be reached is not the same as a document that passed. It never stops a posting either. When the check cannot run at all, the posting completes in every mode, a warning says the document could not be validated, and the queue row records the outcome as Validator unavailable.
The reason is that the fault is ours and not your data: a licence that did not arrive, a rule set nobody uploaded, a validation session that never answered. You can act on none of them, and refusing your posting over our fault would stop the whole company’s invoicing. Block refuses a document the rules rejected. It does not refuse a document the rules could not read.
So this is what to expect when a validation service is briefly unavailable: the document goes, and the message says it was not checked.
The gate runs twice
The check you have just read about runs inside the posting. A second one runs when the document is about to leave, outside any transaction, and asks the same engine with the same mode. Warn tells you and sends anyway. Block tells you and refuses the send, and the queue row goes to Failed with the reason on it.
The second run is there for the cases the first could not judge. A corrected packing slip is one: at the moment the correction is written there is nothing finished to render, so it is judged at the send, and Block stops the wire rather than the posting.
A sensible sequence
- Warn on everything for a month, and read what it finds.
- Fix the two or three rules that fire on nearly every document. They are almost always master data.
- Move invoices to block, partner by partner, starting with the ones who reject strictly.
- Leave the physical documents on warn unless you have a reason not to.