# UBL-CR-682: Move the delivery address into DeliveryLocation

A warning: `cac:Delivery/cac:DeliveryAddress` is outside the invoice model. Write the deliver-to address as `cac:Delivery/cac:DeliveryLocation/cac:Address`.

- Layer: EN 16931
- Severity: warning (the document stays valid)
- Topics: Parties and addresses
- Official definition: https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-tc434/UBL-CR-682/
- Explanation last updated: 2026-09-24

## The short answer

`UBL-CR-682` warns when `cac:Delivery` contains a `cac:DeliveryAddress`. The element exists in UBL but has no place in the EN 16931 model. Move the address into `cac:Delivery/cac:DeliveryLocation/cac:Address`, where the deliver-to address belongs.

This is a warning, and the document stays valid with it. The address it holds, though, is not treated as the deliver-to address by the rules that check one.

## What the rule checks

The check is made once per document, at the root: it looks for a `cac:DeliveryAddress` child of `cac:Delivery`. Its content does not matter; any such element draws the warning.

The severity is warning, so it never makes a document invalid by itself. The recorded invoice with the warning has an outcome of valid, with this as its only finding.

Rules about the deliver-to address look only in `cac:DeliveryLocation/cac:Address`. When tried, a `cac:DeliveryAddress` with no country at all passed `BR-57`, and an intra-community invoice with its delivery country only in `cac:DeliveryAddress` failed `BR-IC-12`.

Checks that apply to every address still reach inside it: when tried, `UK` as its country code was reported by `BR-CL-14`.

| Term | Meaning | UBL element |
|---|---|---|
| BG-15 | Deliver to address | `cac:Delivery/cac:DeliveryLocation/cac:Address` |
| - | Delivery address outside the model (the element this rule reports) | `cac:Delivery/cac:DeliveryAddress` |

## How an integration ends up here

Possible causes, from the shape of the rule rather than from measured usage:

- The UBL was produced from a generic UBL 2.1 template or class library, where `cac:DeliveryAddress` is the obvious field for a ship-to address.
- The invoice is converted from an order or despatch document that carries the delivery address directly under the delivery.
- The UBL schema accepts both paths, so the mapping looked correct until it was checked against the EN 16931 binding.

## How to fix it

1. Replace `cac:DeliveryAddress` with `cac:DeliveryLocation` containing `cac:Address`, and move the address elements across unchanged.
2. Keep the UBL order inside `cac:Delivery`: `cbc:ActualDeliveryDate` first, then `cac:DeliveryLocation`, then `cac:DeliveryParty` if used. When tried, `cac:DeliveryLocation` placed before the date failed the XSD layer.
3. Make sure the moved address has `cac:Country/cbc:IdentificationCode`. Once it is inside `cac:DeliveryLocation`, `BR-57` requires it.
4. If the delivery point has an identifier, such as a GLN, it goes in `cac:DeliveryLocation/cbc:ID`, before `cac:Address`.

## Before and after

These are fragments, not complete documents. The complete synthetic documents they come from are linked below.

Fragment of the invoice with the warning: the address sits in DeliveryAddress, and the invoice is still valid

```xml
<cac:Delivery>
  <cbc:ActualDeliveryDate>2026-09-07</cbc:ActualDeliveryDate>
  <cac:DeliveryAddress>
    <cbc:StreetName>3 Delivery Street</cbc:StreetName>
    <cac:Country>
      <cbc:IdentificationCode>GB</cbc:IdentificationCode>
    </cac:Country>
  </cac:DeliveryAddress>
</cac:Delivery>
```

Fragment of the corrected invoice: the same address inside DeliveryLocation

```xml
<cac:Delivery>
  <cbc:ActualDeliveryDate>2026-09-07</cbc:ActualDeliveryDate>
  <cac:DeliveryLocation>
    <cac:Address>
      <cbc:StreetName>3 Delivery Street</cbc:StreetName>
      <cac:Country>
        <cbc:IdentificationCode>GB</cbc:IdentificationCode>
      </cac:Country>
    </cac:Address>
  </cac:DeliveryLocation>
</cac:Delivery>
```

The corrected invoice wraps the same street and country in `cac:DeliveryLocation/cac:Address`; the other one writes them in `cac:DeliveryAddress`. That document has an outcome of valid and reports only `UBL-CR-682`, a warning. Moving the address removes the warning and puts the address where `BR-57` and the other deliver-to rules look for it.

### What the validator reported

- The invoice with the warning is valid, and reports the warning **UBL-CR-682**. The corrected document passes every layer with no findings.
  - [Download the XML with the warning](https://ironfang.uk/finance/rule-examples/UBL-CR-682-warning.xml)
  - [Download the corrected XML](https://ironfang.uk/finance/rule-examples/invoice-rich.xml)

Recorded on phive 12.1.0 / phive-rules-peppol 4.5.6 / Saxon-HE 12.10, the engine behind the free validator, using synthetic data. A recorded result is regression evidence for these documents; it is not a certification.

## Where it applies

- Credit notes get the same warning. When tried, a credit note with `cac:DeliveryAddress` was valid, with `UBL-CR-682` as its only finding.
- Reported on the EN 16931 layer, which reports UBL elements outside the model as warnings. Neighbouring warnings cover other unused elements, such as `UBL-CR-378` for a country name in the deliver-to address.
- The warning is about where the address is written, not about the delivery itself. `cac:Delivery` with only `cbc:ActualDeliveryDate` draws no warning.

## Related rules

- [BR-57 requires the country code in the deliver-to address, and reads only DeliveryLocation/Address](https://ironfang.uk/docs/finance/rules/BR-57.md)
- [BR-IC-12 fails an intra-community supply whose delivery country is only in DeliveryAddress](https://ironfang.uk/docs/finance/rules/BR-IC-12.md)
- [BR-CL-14 checks the country code wherever the address is written](https://ironfang.uk/docs/finance/rules/BR-CL-14.md)

## Scope and source

Written for Peppol BIS Billing 3.0.21 (May 2026), EN 16931 1.3.16, as applied to UBL 2.1 Invoice and CreditNote documents. Other profiles, syntaxes and releases can define this identifier differently. Guidance version 2026-09-24.1: source checked 2026-09-24, explanation last updated 2026-09-24.

[The official definition of UBL-CR-682](https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-tc434/UBL-CR-682/) carries the normative wording and test. This page is our explanation of it, not a copy.

Guidance does not change the engine verdict. Fixing this finding does not mean the document passes every layer, and validation does not certify legal or tax compliance or transmit a document over Peppol.

## Links

- [This rule as a web page](https://ironfang.uk/docs/finance/rules/UBL-CR-682)
- [Free Peppol invoice validator](https://ironfang.uk/tools/peppol-validator)
- [Rule index](https://ironfang.uk/docs/finance/rules.md)
- [Ironfang Finance API docs](https://ironfang.uk/docs/finance)
- The same rule is available to MCP clients as the tool `finance.rule.get` on https://mcp.ironfang.uk/mcp