Invoices and payments
This page describes the shared invoice lifecycle from both sides, then settlement, disputes, and refunds—without prescribing exact statuses or field names.
Automatic invoices from booking reports (primary path)
For most programmes, invoices are not typed in from scratch. Instead, booking reports are submitted through the API—typically from the buyer’s reservation or order stack, and where enabled from the seller’s property-management or partner stack. Expereon generates invoices automatically from that structured data (single bookings or batches), aligned to the buyer–seller relationship and commercial terms.
That gives finance teams:
- One pipeline from confirmed travel inventory to billable documents.
- Fewer mismatches between what operations sold and what gets approved.
- Hooks for automation (webhooks, logs) so your own systems can react when an invoice is created or changes state.
Sellers often confirm auto-generated invoices when a human check is required, or dispute them when the booking feed is wrong—early correction protects settlement.
Manual, bulk, and adjustment flows (when you still need them)
Alongside API-driven generation, organisations can still:
- Create or edit invoices in the UI when a booking never hit the API or needs a one-off correction.
- Use line items for detailed breakdowns where the product supports them.
- Bulk upload via spreadsheet templates where enabled.
- Save drafts and attach evidence buyers need for audit.
Buyers may occasionally create manual invoices for adjustments agreed outside the normal booking feed.
Buyer review and decisioning
Buyers work a queue of items needing attention:
- Review details alongside booking references carried from the API feed onto the invoice.
- Approve with a chosen payment source consistent with treasury policy (see Key concepts).
- Approve with an adjusted amount when partial recognition is correct.
- Dispute when the invoice does not match operational reality.
- Request information instead of rejecting outright when the issue is missing data.
Efficiency features such as bulk approval or bulk cancellation help finance teams during peak periods.
Seller visibility while invoices evolve
Sellers track status of invoices—most often system-generated from bookings—and can withdraw items that should not proceed, edit invoices that are still pending buyer approval, and add notes when the booking feed needs context.
Because creation is API-driven, sellers should treat confirmation or dispute of bad automation as part of normal operations so bad data never reaches approval.
Settlement
After approval, invoices move through states that reflect due dates and buyer configuration:
- Some obligations settle on schedule around the due date—common when collateral-backed paths reserve capacity until settlement.
- Buyers may pay early from available balance when permitted, improving seller experience.
- Buyers can settle many due items at once or pay a selected batch during treasury operations.
Everyone benefits from payment confirmations that tie settlement to identifiable records. When settlement cannot complete, the platform is designed to surface failures and support retries rather than leaving invoices ambiguous.
If due obligations are not settled in time, invoices may transition to overdue-style states that trigger operational follow-up—exact rules follow your programme configuration.
Disputes
Disputes are a structured conversation:
- Either party can view dispute context.
- Sellers may accept a dispute (cancelling the invoice), correct and resubmit, or reject with evidence.
- If parties cannot converge, disputes can escalate to platform mediation, where a mediator may issue a binding decision for the programme.
Refunds
When bookings cancel or shrink after payment concepts apply, buyers request refunds, sellers review, and outcomes may be approved (full or partial) or denied with reasons. Execution of approved refunds is handled by the system so ledgers stay coherent.