Troubleshoot Sending Documents

This article covers what stops a document going out. Every refused send is written to the Recommand E-Invoicing Log with its reason, including the ones that fail before anything reaches the platform — so "I pressed Send and it refused" always has evidence to look at.

For problems with the connection itself, see Troubleshoot the Connection and Setup.

Customer number has no Peppol Endpoint. Set it on the customer card.

Cause: The customer has no Peppol address, so there is nowhere to deliver to.

Solution:

Open the Customer Card.
Choose Find in Peppol Directory to search by name, or type the endpoint as scheme:value.
Choose Verify Recipient to confirm it resolves on the network.

To fill in many customers at once, see Fill Peppol Endpoints in Bulk.

Sales Invoice number has no VAT Registration No. on its header and customer number has no VAT Registration No. on the card either.

The full message names the rule it breaks:

Peppol BIS 3.0 requires a buyer VAT for standard-rated invoices (BR-S-02).

Cause: A standard-rated document must carry a buyer VAT identifier. Neither the posted document nor the customer card has one.

Solution: Fill in the VAT Registration No. on the customer card. The posted document keeps the value it was posted with, so correct the card and, if the document must go out, credit and re-issue it. The VAT number is not one of the fields Update Document can change on a posted invoice — see the next section for the ones that are.

The credit memo version of this message is identical apart from the document type.

A field on the posted document is wrong. Do I have to credit and re-issue it?

Not always. Business Central lets you change a small set of fields on a posted sales invoice without a credit memo: open the Posted Sales Invoice, choose Update Document, and edit Payment Reference, Due Date, Your Reference, Payment Method Code, Company Bank Account Code, Posting Description, Promised Pay Date, Dispute Status, Shipping Agent Code or Package Tracking No.. The posted credit memo has the same action with its own list.

Solution: Change the field there, then choose Send via Recommand again. The app reads the posted document at the moment it sends, so the corrected value goes out. A wrong payment reference is the usual case, and it never needs a credit memo.

Anything outside that list — the customer's VAT number, the parties, the lines, the amounts — is fixed with a credit memo and a new invoice, exactly as before.

Vendor number has no self-billing agreement.

A self-billed document is only valid where the supplier has agreed that you issue invoices in their name, so turn on Self-Billing Agreement on the vendor card before sending.

Cause: Purchase documents only ever leave as self-billed documents in the supplier's name, and that requires an agreement.

Solution: Switch on Self-Billing Agreement on the vendor card — but only where the supplier really has agreed. This is a legal position, not a checkbox.

Vendor number has no Peppol Endpoint. Set it on the vendor card.

Note that the vendor must also be registered on the Peppol network for self-billing documents, which is a different registration from ordinary invoices - use Verify Recipient to check.

Cause: No endpoint, or an endpoint that cannot receive self-billed document types.

Solution: Set the endpoint, then choose Verify Recipient and Show Peppol Details on the vendor card to confirm the vendor has published the document types you are about to send.

Purchase Invoice number has no VAT Registration No. or Enterprise No. on its header, and vendor number has none on the card either.

A self-billed invoice names the vendor as the seller, and every invoice needs a seller VAT identifier (BR-CO-26).

Cause: On a self-billed document the vendor is the seller, so the vendor's VAT identifier is required.

Solution: Fill in the VAT Registration No. or Enterprise No. on the vendor card.

Vendor number has the same VAT number as this company

so this would be an invoice from us to us. Check the vendor card.

Cause: The vendor carries your own VAT number.

Solution: Correct the vendor card. This usually means a vendor record was created for an internal entity by mistake.

Company Information has neither a VAT Registration No. (W1 field) nor an Enterprise No. (BE local field).

Cause: The sending company's own identity cannot be resolved.

Solution: Open Company Information and fill in one of them.

The send failed and the message includes the payload

A failure returned by the platform comes back with the first part of what was sent:

error We sent the following payload (first 1500 chars): payload

Cause: The platform rejected the document. The reason comes from the platform, not from Business Central.

Solution: Read the platform's error first. The payload is there so you can see what actually went on the wire rather than what you assume was sent — check the parties, the amounts and the VAT categories in it before concluding the app built it wrongly.

The two rules Belgian customers meet most often have their own sections below.

BR-AE-05: a reverse-charge VAT breakdown must have rate 0

[BR-AE-05] In a VAT breakdown (BG-23) where the VAT category code (BT-118) is "Reverse charge", the VAT rate (BT-119) shall be 0.

Cause: A reverse-charge line (medecontractant, VAT category AE) went out with the rate Business Central keeps on the VAT Posting Setup row — 6 or 21 percent — instead of 0. Business Central charges no VAT on such a line but keeps the rate on the row, and its demo data fills Tax Category from that rate alone, so a reverse-charge row carrying S is common. It is not a missing VAT number: that is BR-S-02, above.

Solution: Open VAT Posting Setup, find the row the line uses, and set Tax Category to AE for a domestic reverse charge or K for an intra-Community supply — or leave it blank, and the app derives the category from the line. Nothing on the posted document changes, so choose Send via Recommand again; no credit memo is needed. From version 1.0.0.25 the app sends 0 for every category that charges no VAT and warns when a row contradicts its posting; the readiness FactBox names the row.

BR-CL-23: the unit code is not a UN/ECE Recommendation 20 code

[BR-CL-23] Unit code MUST be coded according to the UN/ECE Recommendation 20 with Rec 21 extension.

Cause: A Unit of Measure whose International Standard Code holds something that is not a Recommendation 20 code. The app never sends the Business Central code (STUKS, UUR, DOOS); it sends the unit's International Standard Code (EA, HUR, BX, KGM) and falls back to C62 ("one") when that field is empty. A wrong value in that field is what reaches the wire.

Solution: Open Units of Measure and correct International Standard Code on the unit the line uses, then choose Send via Recommand again. The readiness FactBox on the posted document lists every unit without a code before you send.

The document was sent, but with a warning

A send can succeed and still report something. The two you will see:

No report is configured in Report Selections for usage usage, so the document was sent without the PDF attachment.

The PDF rendering failed (reason), so the document was sent without the PDF attachment.

Cause: Attach PDF to Outgoing Documents is on, but the report or its layout could not produce a PDF.

Solution: Configure a report for the usage on Report Selection - Sales, or fix the layout. The document itself went out and needs no resend — only the PDF copy was missing.

Still stuck? Send it to support

If none of the causes above match, let the app collect what support needs to see:

Choose the Search icon, enter Recommand E-Invoicing Setup, and then choose the related link.
Choose Send to Support. Business Central opens an e-mail to support@vangeldersolutions.be with a support package attached and the environment, version and warnings already filled in. Describe what you did, what you expected and what happened, then send it.
No e-mail account in Business Central? The package is downloaded instead and your mail program opens - attach the downloaded RecommandSupport_….json to the message.

The support package contains the app's setup without the API secret, the recent log, the job queue state, the e-document services and the warnings the app derived. It contains no document contents, amounts, IBANs or party names; account numbers and e-mail addresses in free text are masked. You can open the file first and read exactly what you are sending.

Prefer to look yourself? Download Support Package on the same page gives you the file without sending anything - the warnings list at the top is the first thing support reads.