XML structures

XML structures provide a standardized data model that separates a document’s content from its presentation. Unlike PDF, which focuses on visual layout, XML emphasizes the semantic meaning of data. This allows Continia eDocuments to reliably exchange, validate, and process documents.

A typical XML structure consists of elements, attributes, and a hierarchical parent-child relationship that forms a tree. Elements represent business concepts or data structures, such as Invoice, ProfileID, and IssueDate. Attributes, on the other hand, provide metadata or qualifiers about an element’s value – such as currency, format, scheme identifier, and language.

In the example below, IssueDate, EndpointID, and PayableAmount are elements, while schemeID and currencyID are attributes.

<Invoice xmlns="urn:oasis:names:specification:ubl:schema:xsd:Invoice-2"
         xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2"
         xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2">

    <cbc:CustomizationID>
        urn:cen.eu:en16931:2017
    </cbc:CustomizationID>

    <cbc:ProfileID>
        urn:fdc:peppol.eu:2017:poacc:billing:01:1.0
    </cbc:ProfileID>

    <cbc:ID>INV-2026-12345</cbc:ID>

    <cbc:IssueDate>2026-09-25</cbc:IssueDate>

    <cac:AccountingSupplierParty>
        <cac:Party>
            <cbc:EndpointID schemeID="0088">
                5790000435944
            </cbc:EndpointID>
            <cac:PartyName>
                <cbc:Name>Contoso Denmark A/S</cbc:Name>
            </cac:PartyName>
        </cac:Party>
    </cac:AccountingSupplierParty>

    <cac:DeliveryTerms>
        <cbc:ID schemeID="INCOTERMS">DAP</cbc:ID>
    </cac:DeliveryTerms>

    <cac:LegalMonetaryTotal>
        <cbc:PayableAmount currencyID="EUR">
            1250.00
        </cbc:PayableAmount>
    </cac:LegalMonetaryTotal>

</Invoice>

Below is a simplified view of the example above, highlighting its parent-child relationship.

Invoice
├─ ProfileID
├─ ID
├─ IssueDate
├─ AccountingSupplierParty
│  └─ Party
│     └─ EndpointID (schemeID="0088")
├─ DeliveryTerms
│  └─ ID (schemeID="INCOTERMS")
└─ LegalMonetaryTotal
   └─ PayableAmount (currencyID="EUR")

The XML Structure View page

The XML Structure View page lists all structures available in the Continia eDocuments database, and each structure lists all its available elements. Structures imported from Continia are pre-configured, therefore there’s no need for modifications unless you need a customization or there are validation errors that can’t be solved otherwise.

To view the structure of an XML file:

1. Search () for and select XML Structure View.
2. Select the desired structure code.

The view follows the XML file itself: the first element is Invoice, then UBLVersionID, and so on. The structure contains every element available in the format, not only the ones that are exported. Elements without data are skipped – therefore, many elements, such as project or contract references, don’t appear in the XML.

To check how a specific element is configured, follow its XML path through the structure until you reach it. For example:

The following columns deserve additional attention.

Understanding default values

When a group appears in the XML, its mandatory children must have a value. Under the root Invoice, elements such as UBLVersionID, CustomizationID, ID, and IssueDate are mandatory. A mandatory element without a mapped value takes its value from Default Value. E.g.: UBLVersionID has the default value 2.0, and CustomizationID has the default value OIOUBL-2.02.

Groups such as AccountingSupplierParty and AccountingCustomerParty are always exported because an invoice always needs a sender and a receiver. Their children follow the same rules.

Troubleshooting validation errors

One of the key features of XML is its support for schema validation. Schemas specify which and how many times elements are allowed, their data types, and their relationships – enabling Continia eDocuments to verify that an eDocument is structurally and semantically correct before processing it.

If an eInvoice fails to pass validation, its eDocument status is set to Not Valid. To troubleshoot this:

1. Search () for and select Posted Sales Invoices.
2. Click the No. of the desired eInvoice and, on the Posted Sales Invoice page, click the value of the eDocument Status field.
3. On the eBilling Outgoing Document Card, click Validation Log on the action bar.
4. Error messages shown in this log come from the schema related to the XML structure, such as a requirement encoded by a government in the UBL format. Copy the error message and look it up using a search engine or AI chatbot.
5. If the error message includes a business term code (e.g.: BT-3), go to the XML Structure View, click the funnel icon on the action bar, click Filter and select Business Term. Then, paste the business term code in the filter to locate the related element.

If you're still unable to address the issue, contact Continia’s Support team with what you found: the error, the business term, the element, and what is wrong. For example, “BT-3, InvoiceTypeCode, missing”. The more relevant information you provide, the better.

Modifying XML structures

There are three ways to modify XML structures.

Structural modifications

Apply a quick fix to a missing or incorrect element, such as mapping it to a field or setting a default value. However, these modifications are lost when the structure is imported again from the configuration, so use this method for fixes you can afford to reapply.

To modify an XML structure:

1. Search () for and select XML Structure View.
2. Select the desired structure code.
3. Select the desired element.
4. Fill out the element's mapping or default value. E.g.: map InvoiceTypeCode to a field on the eBilling Header table (table 6225510).

Structural extensions

Make permanent changes that survive re-imports of the base structure. The extension is a separate copy that overrides only the elements you change. For more information, see Creating XML structure extensions.

Scenario framework

Change values per use case on the document, so that a value can depend on the circumstances of a particular document. For more information, see eDocuments scenarios.