DPDgroup GeoData

Documentation Review Status
Last reviewed: June 2026
Reviewed and validated by the DPD Customer IT team.

  1. Download the GeoData specifications

    The data specifications last update : 06/2026

    In the sections below you will also find a more specific explanation of some of the commonly used non-standard service codes such as B2C Predict, B2C Parcelshop, etc.

  2. Encoding

    UTF-8 is the only allowed encoding of all data types sent towards DPD Belux from 2022 onwards.

    Please change all possible configurations away from ISO-8859-1 or other encoding type into UTF-8

  3. Correctly naming your EDI file

    Your EDI file’s name needs to have the correct format for our system to pick it up from our SFTP. An incorrect name format will result in the system not recognizing it and your data not being processed.

    The correct naming is as follows (bold parts are fixed, italic parts are variable):

    GEODATA_SHPNOTCUS_[YOUR DELISID]_034[YOUR DEPOT CODE]_D[DATE]T[TIME]_[6 DIGIT COUNTER]

    • Your DelisID is assigned to you by DPD.
    • Your depot code is always 4 digits and is also assigned to you by DPD.
    • The data is in format YYYYMMDD
    • The time is in format HHMMSS
    • The counter exists only to make sure no file will overwrite the other if they’re created on the exact same second. It needs to be 6 digits.

    An example:

    • Your DelisID is BE2625
    • Your depot code is 0541
    • You create this file on January 22nd, 2025 at 16h51 and 32 seconds.
    • You have a new counter running

    Your file name would be
    GEODATA_SHPNOTCUS_BE2625_0340541_D20250122T165132_000001

    If you were to make another datafile on the exact same second, it would be named
    GEODATA_SHPNOTCUS_BE2625_0340541_D20250122T165132_000002

  4. B2C Predict shipment

    • Service code: 327 for normal parcel, 328 for small parcel
    • Extra required line: MSG line

    This service code allows you to have DPD send a Predict message to the receiver. For obvious reasons, this implies you need to know either the email address or phone number of the receiver. We usually advise using the email address.

    You also have to add a new line to your EDI: the MSG line. You can find the details of this line in the previously mentioned dataset

    In this line, 4 fields are mandatory:

    • MSGTYPE: use 1 if it’s an email, 2 if it’s a text message.
    • MSGDESTINATION: email or phone number to send the Predict to. If the type is 1, this must be an email. If the type is 2, it must be a phone number
    • MSGTRIGGER: this is an internal DPD code and can be hardcoded to 904 for these shipments.
    • MSGLANG: the language in which the Predict must be sent. Please note only English or the recipient country’s official language are accepted. This needs to be the official Two letter ISO language code

    You can have several MSG lines within your shipment. However, it’s worth noting that the MSG line is an “all or nothing” deal. This means if you add an MSG line to your data, you need to make sure all it’s mandatory fields are filled in. If, for example, you have an MSG line without the language code, the line will be considered faulty and be ignored, meaning the Predict will not be sent.

    Example can be downloaded here.

  5. GeoData Service Templates

    To help integrators understand how GeoData files are structured for specific DPD services,
    a set of sample templates is provided below.

    Each template contains a complete example of a valid SHPNOTCUS file and highlights
    the service-specific information required for successful processing.

    The examples are intended as implementation guides and can be used as references when
    generating GeoData files from your own systems.

    Important All examples follow the standard GeoData hierarchy:

    • Shipment information (SHIPMENT)
    • Sender information (SENDER)
    • Receiver information (RECEIVER)
    • Parcel information (PARCEL)
    • Optional service-specific subtypes

    The service used for a shipment can always be identified through the SERVICECODE field located in the PARCEL subtype.

    Standard B2B Shipment (Service 136)

    [TEMPLATE] – B2B 136 Geodata shpnotcus file
    This template demonstrates a standard Business-to-Business shipment using service code 136.

    Key points

    • The service is identified by SERVICECODE = 136.
    • No additional service-specific subtype is required.
    • Sender, receiver and parcel information are sufficient for shipment creation.
    • This template can be used as a baseline for most standard B2B integrations.

    When troubleshooting a GeoData file, the first field to verify is the
    SERVICECODE in the PARCEL record, as it determines how the shipment
    will be processed within the DPD network.

    B2B Predict Shipment (Service 136 + Predict)

    [TEMPLATE] – B2B Predict 136 Geodata shpnotcus file

    This template demonstrates a B2B shipment with Predict notifications enabled.

    Additional requirements

    • A MSG subtype must be present.
    • The receiver’s email address or mobile phone number must be provided.
    • Predict communication settings are configured through the MSG fields.

    Mandatory MSG fields

    • MSGTYPE
    • MSGDESTINATION
    • MSGTRIGGER
    • MSGLANG

    If one of the mandatory MSG fields is missing, the Predict notification will not be
    generated even if the shipment itself is accepted successfully.

    B2C Predict Shipment (Service 328)

    [TEMPLATE] – B2C 328 Geodata shpnotcus file

    This template demonstrates a Business-to-Consumer shipment using service code 328.

    Key points

    • SERVICECODE = 328
    • Predict notifications are mandatory.
    • Receiver contact information must be supplied.
    • A valid MSG subtype must be included.

    Mandatory MSG fields

    • MSGTYPE
    • MSGDESTINATION
    • MSGTRIGGER
    • MSGLANG

    The destination contact information should always be validated before file generation,
    as invalid contact details will prevent Predict notifications from being delivered.

    ParcelShop Delivery (Service 337)

    [TEMPLATE] – Shop 337 Geodata shpnotcus file

    This template demonstrates delivery to a DPD ParcelShop using service code 337.

    Additional requirements

    • SERVICECODE = 337
    • The destination ParcelShop identifier must be provided in the receiver information.
    • The ParcelShop identifier determines the final delivery location.

    To retrieve a valid ParcelShop identifier, use the ParcelShop Locator service.

    ParcelShop Locator Documentation

    The ParcelShop ID returned by the Locator service must match the value inserted into
    the GeoData file. If the identifier is invalid or no longer active, the shipment may
    be rejected or routed incorrectly.

    Understanding Service Identification

    For all GeoData shipment files, the service associated with a shipment is determined by
    the SERVICECODE field located in the PARCEL subtype.

    Service Description
    136 Standard B2B
    101 Small B2B
    136 or 101 + MSG B2B Predict
    328 B2C Predict
    327 Small B2C Predict
    337 ParcelShop Delivery

    When analysing a GeoData file, the PARCEL subtype should therefore always be checked first,
    as it defines the service and determines which additional data may be required.

    ⚠️Important Notice

    The templates provided in this section are intended as implementation examples
    and reference guides for common DPD services.

    Although these examples reflect the current GeoData specification, service requirements,
    mandatory fields, supported subtypes, and validation rules may evolve over time as the
    DPD network and interoperability standards continue to develop.

    For this reason, implementing a template exactly as provided in this documentation does
    not automatically guarantee production readiness or long-term compatibility.

    Before moving an integration into production, DPD strongly recommends submitting your
    generated GeoData files for validation by the Customer IT team.

    The validation process helps ensure that:

    • The file structure complies with the latest GeoData specifications.
    • Mandatory service-specific fields are present.
    • Routing and operational requirements are correctly implemented.
    • Predict, ParcelShop, Return and other service-specific configurations are correctly configured.
    • Future operational issues can be avoided before go-live.

    For validation requests or integration assistance, please contact:

    it.cs@dpd.be

    As DPD standards may evolve over time, periodic reviews of existing integrations are
    also recommended to ensure continued compliance with the latest GeoData requirements.

     

  6. Moving from Legacy Formats

    When moving from the DPD DE legacy format to Geodata, you can find help in:

    When moving from the DPD DE legacy format to API Integration, you can find help in:

  7. Heavy parcel regulation in Germany

    Rules will be applied for heavy parcels starting Sept 2026. This means that your GeoData must contain the correct weight of the parcel. Concretely, you need to ensure that the DECLAREDWEIGHT field in the PARCEL line is correctly filled in, with a value that matches the real weight of the parcel.

    Of course, the MPSWEIGHT field in the SHIPMENT line still needs to contain the total weight of the shipment: the sum of all weights of all your parcels within that shipment.

    There are also mandatory changes to the labels which are listed on this page.

Was this post helpful?(Required)