SDK 5.3.0 and CLI 0.12.1 — offline validation catches up with the network

@getpeppr/sdk 5.2.0 left a gap: the published package could accept a document the network refuses, or refuse one the network accepts. Version 5.3.0 closes the classes of divergence that merged since, so a developer validating locally fails at the right place — before the send, not after.

Profile rules on the document type

validateSchematron() now enforces the three Peppol billing-profile rules that govern invoiceTypeCode (GPR-884):

• PEPPOL-EN16931-P0100 — invoices must use one of the 26 type codes the billing profile allows.
• PEPPOL-EN16931-P0101 — credit notes are restricted to their 5 codes.
• PEPPOL-EN16931-P0112 — codes 326 and 384 are reserved for domestic German documents: both buyer and seller must be German organizations.

These apply to the UBL document the SDK builds. The JSON send route (POST /v1/invoices) derives the document kind from isCreditNote and ignores invoiceTypeCode — so these rules matter when you produce or check UBL, not as a prediction of what the gateway rejects at send time.

Six structure rule IDs now say what they check

Following the 5.2.0 audit of validateSchematron(), the structure findings from validateInvoice() went through the same reverse audit (GPR-1267). Verdicts are unchanged; the IDs move to the rules they actually verify:

• buyer name BR-06 → BR-07 (BR-06 is the seller name)
• buyer street, city, postal code BR-50/BR-51/BR-53 → GETPEPPR-BUYER-ADDRESS (a delivery-contract check; the borrowed IDs are payment and currency rules)
• line VAT rate BR-CO-17 → GETPEPPR-LINE-VAT-RATE
• taxCurrencyRate BR-53 → GETPEPPR-TAX-CURRENCY-RATE
• buyer-reference warning BR-10 → PEPPOL-EN16931-R003
• due-date warning: no rule ID (no rulebook rule mandates one)

CLI 0.12.1

@getpeppr/cli 0.12.1 rebundles SDK 5.3.0, so getpeppr validate and getpeppr convert --validate enforce the profile rules too — documents outside the profile now fail these commands, and exit codes change accordingly. The structure section no longer repeats warnings the countryRules section already reports, so each warning is counted once. getpeppr send keeps a JSON-send preflight aligned with the API contract: the profile rules on the ignored invoiceTypeCode field cannot block a send (GPR-1285). (Version 0.12.0 spent a few minutes on the registry with a stale SDK bundle and is deprecated; 0.12.1 is the one to install.)

Upgrading

npm install @getpeppr/sdk@5.3.0
npm install --global @getpeppr/cli@0.12.1

If you filter findings by ruleId, update those filters using the mappings above. If you only react to valid, errors or warnings, no decision-logic change is required — but documents outside the billing profile now fail local validation where they previously passed.