Transaction History overview
Transaction History is the financial audit ledger for your bookings. Every payment, cost line, refund, and cancellation that touches a booking in your Salesforce org is captured as an immutable event — classified with an accounting-compatible transaction code, stamped with the booking it belongs to, and never edited or deleted afterwards. A correction is always a new event, so the ledger reads the way an auditor expects: what happened, in order, with nothing overwritten.
On top of the event ledger, a configurable general-ledger layer derives double-entry journal entries from each event, giving finance a trial balance per GL account and currency that reconciles back to individual bookings.
All examples in this section come from the Meridian Travel Co. reference implementation — see How tenants work.
Why it exists
- A finance-grade audit trail. Salesforce records change in place; finance needs the history. The ledger records every financial movement as it happened, including the ones later reversed.
- Parity during migration. Tenants moving off a legacy reservation system can compare the ledger's per-booking, per-code net amounts against the legacy system's transaction reports code-for-code, because events are classified with compatible TR codes.
- A "what changed" feed. Finance and downstream systems can ask "which bookings had financial activity since 6am?" — either through the customer API or a queryable timestamp field in your org — instead of scanning bookings.
The three surfaces
| Surface | Who uses it | What it shows |
|---|---|---|
| Finance console | Finance teams | All events, filterable; per-code summaries; trial balance; CSV export; ad-hoc SQL |
| Booking-page embed | Agents and finance in Salesforce | One booking's audit trail with a running balance, on the booking record page |
| Customer API | Your finance and data systems | The same ledger as JSON — events, summaries, trial balance, change feed |
What makes it trustworthy
- Append-only. Events are never updated or deleted. Cancellations and refunds are new events with a
C(cancel) indicator. - Nothing is silently dropped. A payment method the classification does not recognize still produces an event, coded
UNKand booked to a suspense account for review. - GL rules replay, events do not. Chart-of-account changes regenerate journal entries from the untouched event stream — see Data model.
- Human references first. Every event carries the booking number your teams quote, the trip name, and a readable record label alongside the Salesforce ids — see Data model.