The flows
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 | Nothing. The document 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 |
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.
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 ruleset that cannot be reached is not the same as a document that passed. In warn mode the document goes and the message records that it could not be checked. In block mode the posting is refused, because block means block and an unchecked document is not a checked one.
This is the behaviour to expect when a validation service is briefly unavailable, and it is the reason to move to block deliberately rather than everywhere at once.
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.