The deterministic invoice UUID (IBR-002-OM)

IBR-002-OM — deterministic UUIDs

The invoice UUID (BTOM-002) must be a version 5 UUID, not random, and the Solution Reference Architecture v1.0.3 (section 10.2.3) fixes how it is derived: UUIDv5 in namespace e0bc4ac8-b025-46e5-a76d-0c893fc3027e over seven fields — eight on a profit-margin invoice or profit-margin self-invoice — joined by single spaces:

IBT-034-1 scheme · IBT-034 seller electronic address · IBT-003 type code
IBT-001 number   · IBT-002 date                      · IBT-110 VAT total
IBT-112 total with VAT        (+ BTOM-020 total amount due, profit-margin only)

Amounts enter the seed as the exact strings in the XML. The Architecture assigns the derivation to C2, the sending access point, so it is the same value C3 and the Tax Authority derive from the document — which is what makes the preceding-invoice reference in IBR-032-OM verifiable.

On the rendered paths GoRoute derives it from the finished document. On POST /api/v1/documents the Schematron only checks the shape, so GoRoute also checks the value: a cbc:UUID that is not the derivation is refused, with the expected value in the error, and POST /api/v1/documents/validate reports it as a BTOM-002 error before you send.

Until 10 November 2026 (9 November on the test service), GoRoute left BTOM-020 out of this check, so it refused a profit-margin invoice whose UUID was derived over all eight fields as a mismatch. If one of yours was refused that way, send it again.