Reporting and reconciliation integration

Retrieve operational and financial order data for reporting, reconciliation and downstream processing.

A Reporting and reconciliation integration uses order data to support back-office workflows after an order has been created.

Unlike Post-booking management, which supports traveller-facing order management, Reporting and reconciliation is designed for operational, finance and reporting workflows.

Use order data to:

• Reconcile transactions with your internal systems.
• Build operational and financial reports.
• Validate payment and commission information where available.
• Export order data to downstream systems.
• Support accounting, auditing and business intelligence workflows.

The information available depends on the travel service, order and API version.

Choose this integration if you want to:

• Build finance or accounting workflows using order data.
• Reconcile orders with your internal records.
• Generate operational or financial reports.
• Export order data to internal or downstream systems.
• Validate payment, pricing or commission information where available.
• Use order data for business intelligence or analytics.

Before implementing this integration:

• Complete the Demand API prerequisites.
• Make sure you have the identifiers required to retrieve the relevant orders.
• Define which order data your reporting or reconciliation workflow requires.
• Define how Demand API order identifiers map to records in your internal systems.

If your application creates orders using the Demand API, store the identifiers required for subsequent order retrieval and reporting.

A Reporting and reconciliation integration retrieves order data from the /orders/details endpoint and processes it in your internal reporting, finance or operational systems.

Unlike traveller-facing integration flows, reporting and reconciliation usually happens after order creation and can run independently of the traveller journey.

A typical reporting and reconciliation workflow follows these steps:

Use the relevant order details endpoint to retrieve information for an order.

Depending on the travel service, and API version, the response can include:

• Order and reservation identifiers.
• Order or reservation status.
• Traveller information.
• Travel dates and itinerary information.
• Pricing information.
• Payment information.
• Taxes and charges.
• Commission information where available.
• Travel-service-specific information.

Retrieve only the information required by your reporting or reconciliation workflow and use the relevant API response as the source for current order data.

Use stable identifiers to associate Demand API orders with the corresponding records in your internal systems.

A reconciliation workflow can compare information such as:

• Order identifiers.
• Order or reservation status.
• Prices and charges.
• Payment information.
• Taxes.
• Commission information where available.
• Other values required by your accounting or operational processes.

Define how identifiers and financial values map between the Demand API and your internal data model before automating reconciliation.

When values do not match, preserve enough information to identify the affected order and investigate the discrepancy.

Use order data to support the reporting requirements of your organisation.

Common use cases include:

• Financial reconciliation.
• Accounting and invoicing.
• Commission validation.
• Operational reporting.
• Payment reconciliation.
• Business intelligence and analytics.
• Exporting order data to data warehouses, ERP systems or other internal platforms.

Keep the transformation between Demand API data and your internal reporting model explicit. This makes it easier to identify whether a value comes directly from the API or has been calculated or transformed by your application.

Order data can contain both common information and travel-service-specific information.

When your reporting workflow supports multiple travel services:

• Use common order identifiers and fields where applicable.
• Handle travel-service-specific data explicitly.
• Do not assume that every field is available for every travel service.
• Allow for optional or unavailable information in your downstream data model.
• Refer to the relevant API reference when adding support for another travel service.

This approach lets you reuse common reporting logic while handling differences between travel services where required.

Order information can change after an order is created.

For example, an order or reservation can be modified or cancelled after your reporting system has retrieved it.

Design your reporting and reconciliation workflow so that changes to relevant order information can be reflected in your internal systems.

In particular:

• Do not assume that previously retrieved order information is permanently current.
• Retrieve current order information when your workflow requires the latest state.
• Define how changes in order or reservation status are reflected in downstream systems.
• Avoid treating stored operational or financial data as current when the underlying order can still change.

Validate the information required by your finance or reconciliation workflow before importing or processing it in downstream systems.

Your implementation should:

• Check that required identifiers are present.
• Handle optional or unavailable financial fields.
• Validate expected data types and values.
• Keep the original order identifiers associated with transformed or exported records.
• Handle discrepancies without silently overwriting internal records.

Both integrations use order data, but they serve different purposes.

Your reporting workflow should distinguish between API errors, incomplete data and reconciliation discrepancies.

For example:

• API request fails — Handle the error according to the API error response and retry only where appropriate.
• Required data is unavailable — Do not invent or infer missing values. Handle the record according to your reporting requirements.
• Order data does not match an internal record — Record the discrepancy and retain the identifiers required to investigate it.
• Order state has changed — Process the current state according to your reconciliation rules.

Before considering your Reporting and reconciliation integration complete, verify that:

Reporting and reconciliation uses existing order data for operational and financial processing. It does not provide the traveller-facing capabilities required to discover, create or manage orders.

• To let travellers search for travel products and create orders on your platform, use the Search, look and book integration.
• To let travellers retrieve or manage existing orders, use the Post-booking management integration.

After implementing Reporting and reconciliation:

1. Test order retrieval for the travel services supported by your reporting workflow.
2. Verify how Demand API order identifiers map to records in your internal systems.
3. Test your processing logic with different order states and available data.
4. Validate financial and reconciliation rules before using the workflow in production.
5. Test how changes to existing orders are reflected in your downstream systems.
6. Test error and discrepancy handling.
7. Review the Orders FAQs for common questions about order data and statuses.
8. Review the relevant Orders API references for the data used by your reporting workflow.