Transaction Management
Last updated
Last updated
Transaction Management provides a systematic way to link EUDR compliance data with the product level information required to evidence compliance with the Regulation in the form of a Due Diligence Statement (DDS) in the EU Information System (EU TRACES). It enables key information from your ERP, such as Purchase Orders and Sales Orders, to be captured in these DDS as well providing a way of managing linkages with existing DDS and connections between different product level documentation.
Transaction Management is a premium feature in TradeAware. To use this functionality, your account must be enabled for transactions. If you do not have this enabled, contact your Customer Success Manager.
Your business will also need to have an identifier added to the account details to submit a transaction to TRACES. This must be an EORI for import and export transactions but can be VAT for domestic (internal EU transactions). You can update this in your Manage Account page.
Your business will need to be connected to a business with plots of the relevant commodity to submit a Transaction to TRACES.
You will be able to see the data with your associated account on TRACES. By default the system is connected to the ACCEPTANCE testing system of TRACES and can be connected to the PRODUCTION environment when you are ready to submit legally valid due dilligence statements.
Transaction Management provides a way to link transaction data, such as Purchase Orders (PO) and Sales Orders (SO) to compliance data in TradeAware to create and manage Due Diligence Statements.
Customers can:
Manage Due Diligence Statements: Link orders from your ERP system to compliance data in TradeAware.
Enhance Traceability: Connect DDS compliance data to orders, streamlining regulatory reporting and audit preparation.
Automate Compliance Workflows: Minimize manual data entry by automating key compliance and transaction workflows.
Basic Transaction Management for Operators
Basic Transaction Management for Traders
Managing Composite Products
Submitting Transactions to TRACES
Linking Transactional Data to Compliance Workflows (e.g. Batches, Shipments)
Component Object: Represents a commodity or product, including essential details like type, quantity, and origin, traceable to the supplier or production location. Components are mapped to the requirements for validly creating a Due Diligence Statement in the EU Information System (EU TRACES).
CustomData: Metadata related to the transaction. This flexible structure allows users to store relevant information, provided it follows these rules:
Maximum of 10 keys.
Data must be of type string, number, or boolean. Arrays are not supported due to validation and storage constraints.
supplierBusinessId is a unique identifier representing the supplier's business in the TradeAware system. This identifier is used to establish a direct link between a transaction and its immediate supplier, ensuring their required data can be captured against a Due Dilligence Statement.
ddsReferences: Links a transaction component to one or more Due Diligence Statements (DDS), ensuring compliance and traceability. Each DDS in the array includes:
id: Unique identifier for the DDS.
verificationNumber: Code validating the DDS’s authenticity.
Validation Rules:
When a DDS reference is included in a transaction, the system will verify both the DDS ID and the verificationNumber before submission.
If the TRACES API is unavailable or returns an unknown error, new transactions referencing DDS numbers will be rejected with a recommendation to message.
Transactions progress through various statuses during their lifecycle, from creation to final processing in the EU Information System (EU TRACES) as a Due Diligence Statement (DDS). Below is an overview of each status:
DRAFT: The transaction is in draft mode, still being prepared and not yet submitted for processing. It remains editable by the user.
TO_SUBMIT: The transaction is pending submission to the EU Information System. At this stage, all necessary data should be finalized.
SUBMITTED: The transaction has been successfully submitted to TRACES and is waiting for validation. This does not guarantee that a DDS reference number or verification number has been assigned. Once fully approved by TRACES, these numbers will be assigned to the transaction. This process might take up to a few hours or, in some cases, longer, depending on TRACES' response times.
WITHDRAWN: The transaction was withdrawn from TRACES and is no longer active. No DDS reference or verification number will be assigned to a withdrawn transaction.
⚠️ Important Notes:
Transactions in DRAFT, TO_SUBMIT, or WITHDRAWN states do not return a DDS reference or verification number.
Operators and traders play distinct roles in the compliance chain under the EU Information System (EU TRACES).
Operators are the first person to make a product available on the EU market. Their transactions focus on direct traceability to immediate suppliers, requiring a supplierBusinessId but excluding ddsReferences.
Traders are those to subsequently move products already available in the EU market around it. Their transactions emphasize linking products to existing DDS references, requiring ddsReferences but not supplierBusinessId. It is important to avoid including both supplierBusinessId and ddsReferences in a single request to prevent errors and maintain traceability integrity.
Why the Distinction? The EU TRACES design separates these responsibilities to reduce duplication of effort. An entity must choose between associating a transaction with supplierBusinessId or ddsReferences, not both. This ensures that existing available information in the EU TRACES system does have to be re-entered.
Common Challenges and Clarifications:
If both supplierBusinessId and ddsReferences are included in a request, the system will throw an error. This is because EU TRACES does not require both properties together for a single component.
Users should ensure they store supplier and DDS information separately in their systems if needed for later traceability.
DDS Reference Validation in Transactions API
When referencing a previously submitted Due Diligence Statement (DDS), the API performs validation checks to ensure the provided DDS ID and verificationNumber are correct.
Error Handling:
If the provided DDS reference is invalid or does not match, the API will return:
If the TRACES system is unavailable, new transactions using DDS references will be rejected with an instruction to retry later.
Business Case:
Operators need a reliable way to link different type of orders from their ERP systems to compliance workflows. Ensuring accurate traceability at the point of importation is critical for meeting EUDR requirements.
Solution:
The Transactions API allows operators to link order data directly to their immediate suppliers, enabling efficient management of Due Diligence Statements and compliance workflows.
Create a New Transaction as an Operator:
Description: This is for the entity that is the first to import goods into the EU. Operators are responsible for ensuring that products meet EUDR compliance at the initial point of entry into the EU market.
Key Requirements:
supplierBusinessId is required to link the transaction to the immediate supplier.
ddsReferences should not exist in the request body.
The focus is on maintaining traceability to the immediate supplier rather than upstream DDS references.
Steps to Implement:
Retrieve a list of suppliers:
Endpoint: GET /business-connections/suppliersendpoint to fetch supplier details.
Important: When linking a transaction to a supplier, you can use any of the following identifiers: EORI, VAT number, email, or the customData field if none of the other identifiers are sufficient. We recommend prioritizing EORI or VAT for better traceability and compliance alignment.
Example Request:
This returns a list of all the business connections that have you as sourceBusiness with the data of your suppliers in targetBusiness (for each item in the list). Check what sourceBusiness and targetBusiness mean in our API reference for business connections
Your {businessId} can be found in the sourceBusiness field under id.
Your supplier's unique identifier (id) is located in the targetBusiness field.
Create a transaction with supplier-linked components:
Endpoint: POST /transactions
Example Request:
List all transactions:
Endpoint: GET /transactions
Example Request:
Update an existing order:
Endpoint: PATCH /transactions/{transaction_id}
Example Request:
Business Case:
Traders must comply with regulatory requirements by ensuring traceability of DDS references for each transaction. Forwarding upstream DDS references can be complex when dealing with multiple components.
Solution:
Use the Transactions API to include DDS references in transaction components, ensuring compliance and transparency.
Create a New Transaction as a Trader:
Description: This is for entities that make relevant products available on the market. Traders are involved in the subsequent movement of goods and must link products to their immediate suppliers.
Key Requirements:
supplierBusinessId should not exist in the request body.
ddsReferences should be provided for traceability.
The focus is on associating products with upstream DDS references.
Steps to Implement:
Create a transaction with DDS references:
Endpoint: POST /transactions
Example Request:
Note: The system will validate the provided DDS ID and verificationNumber before accepting the transaction.
Retrieve Information from an existing DDS
Optional: This action allows you to retrieve and check the data in a reference DDS before making use of it.
Endpoint: GET /dds/fetch-dds-data
Example Request:
Business Case:
Managing products composed of multiple components while ensuring compliance requires a structured approach to track each material’s origin and DDS references.
Solution:
Use the Transactions API to associate components with composite products, maintaining traceability for compliance.
Steps to Implement:
Create a composite product with multiple components:
Endpoint: POST /transactions
Example Request:
Add a component to a transaction:
Endpoint: POST /transactions/{id}/components
Example Request:
Update a component to modify DDS references:
Endpoint: PATCH /components/{id}
Example Request:
Business Case:
Businesses need to ensure transactions are ready for submission to the EU Information System (TRACES). This step is critical for regulatory compliance but requires careful validation and preparation.
Solution:
Use the submit endpoint to update a transaction’s status to TO_SUBMIT, signaling its readiness for TRACES submission.
Steps to Implement:
Submit a transaction:
Endpoint: PUT /transactions/{id}/submit
Example Request:
Example Response:
Receiving a DDS Reference and Verification Number
After a transaction is successfully submitted to TRACES, the system continuously checks for the assigned DDS reference and verification number. Since TRACES assigns these asynchronously, TradeAware automatically retrieves and updates them. Users can access this information by querying the transaction details, ensuring they receive real-time updates on compliance status.
Endpoint: GET /transactions/{id}
Example Request:
Example Response:
The dds object in the API response contains details such as:
tracesDdsReferenceNumber: Official DDS reference number from TRACES.
tracesDdsVerificationNumber: Code that validates the DDS authenticity.
submittedAt: Timestamp indicating when the transaction was sent to TRACES.
Disclaimer: The DDS reference and verification number are only returned for transactions with the status "SUBMITTED". Transactions in DRAFT, TO_SUBMIT states will not return any DDS reference or verification number.
Business Case:
Businesses need to link transactional data, such as batches, shipments, Purchase Orders etc. to compliance workflows to create a robust audit trail and maintain regulatory compliance. Without this linkage, inefficiencies and compliance risks can arise.
Solution:
Leverage the customData field in the Transactions API to associate SOs with POs for seamless traceability.
Create a Batch linked to a purchase order:
Endpoint: POST /businesses/{businessId}/transactions
Example Request: