Compare

UnityTrip and SAP S/4HANA.

SAP S/4HANA is the ERP that keeps an operation running: maintenance, budgets, scheduling, procurement, HR and the ledger behind them, from the purchase order to the plant. UnityTrip does not replace it. It is the operating layer for travel and fleet that sits above the ERP: staff profiles, budgets, currencies and balances come in from SAP each day, bookings, approvals, quotas and claims run against them, and postings for expense claims go back.

This page sets out where the boundary between the two sits, what crosses it, what happens when the feed is wrong, and why workforce travel is better run above the ledger than inside it. SAP's travel product, Concur, is a separate system and has its own comparison.

What S/4HANA is for

Running the operation. S/4HANA is where maintenance is planned, budgets are held, work is scheduled and procurement runs, with the general ledger, HR master records and identity underneath, and the financial controls, segregation of duties and audit posture a regulated operator depends on. It changes on managed release cycles, because the system that runs the plant should. That stability is the point, and it is not something a travel platform should try to reproduce.

What UnityTrip is for

The fast-changing operational layer the ledger is not built to express: booking across owned, leased, chartered and commercial transport; entitlement, priority, quota and displacement rules; seat allocation, go-shows and manifests; budget approval at the point of booking and expense claims in the same record. The local and company-specific quirks that a standard product leaves offline are modelled here so they reach the posting. Change is configuration of the tenant's model, and it ships continuously without touching SAP.

Dimension UnityTrip SAP S/4HANA
Role in the landscape Operating layer for travel and fleet, above the ERP System of record that runs the operation: maintenance, budgets, scheduling, procurement, HR and identity
What it holds Journeys, seats, manifests, policy decisions, approvals and claims as an event stream The general ledger, cost centres, budgets, purchase orders and employee master records
Owned and leased fleet Native: utilisation, seat allocation, go-shows and partner asset-sharing are the core of the platform Transport assets appear as cost lines and maintenance objects, not as bookable inventory
Travel policy Executed deterministically at booking: entitlement, priority, quota, booking windows, penalties Not in the ERP; SAP's travel product is Concur, a separate system compared on its own page
Master data Consumed from SAP each day: staff profiles, budgets, currencies and balances Owned and maintained here; accuracy depends on the people and processes keeping it current
Finance postings Produced as governed data: for business bookings no payment executes without an approved claim number Received and journalled; the ledger stays the ledger
What reaches the posting Everything the tenant actually does: offline bookings, in-country payment gateways, subscription expenses and other local quirks are modelled and posted, not left outside the system Whatever it is sent; anything the feeding systems cannot express never reaches the ledger
Upstream data quality Designed on the assumption that the feed will sometimes be stale or wrong; discrepancies are visible with an event trail back to the source record As good as the master-data maintenance behind it
Fault tolerance Fault-tolerant geo-replication, right-sized per tenant, so the travel platform itself does not fail; if the ERP is down, travel still moves and postings wait. Priced by the cost per guaranteed performant transaction Enterprise availability as a platform; when it is down, postings and claims queue until it returns, and travel does not stop
Pace of change Continuous; a tenant's rules change as configuration of the model, not as a release project Managed release cycles, typically measured in months, with customisations carried through upgrades
Architecture Distributed, event-sourced, cloud-native on Microsoft Azure; work is queued and streamed Integrated suite on the SAP HANA in-memory database, run on-premise, in private cloud or as a cloud edition
Demand surges Designed to absorb 10 to 1000x bursts from schedule changes and crew rotations; work is queued and streamed and cost follows what runs Sized and licensed for peak memory, so capacity bought for the peak sits idle between peaks
Constrained networks Lean payloads and few round trips for field sites and remote camps Assumes reliable corporate connectivity
Time to deploy Weeks; onboarding is configuration, and the SAP connection is tailored per client An implementation programme; already in place at most organisations UnityTrip serves
Commercial model Subscription via the Microsoft Azure Marketplace, billable against committed Azure spend Enterprise licensing with infrastructure and integrator services

What crosses the boundary

Master data in, governed postings out.

The connection is over SAP RFC (Remote Function Call), personalised to each client's SAP configuration because no two are alike, and bidirectional. It is in production today. Every exchange is recorded as an event, so the trail from a master-data change to the booking it affected to the posting it produced is complete by construction.

From SAP into UnityTrip

  • Staff profiles: locations, grades and policy groups that decide what a traveller is entitled to and which rules apply.
  • Budgets and cost centres, so approval at booking is against the real allocation.
  • Currencies and balances, refreshed each day, so claims and payments are made against current figures.
  • Identity, so access follows the organisation's own directory rather than a separate user list.

From UnityTrip back to SAP

  • Postings for approved expense claims: the claim number is the chokepoint, and for business bookings no payment executes without one.
  • Cost allocations per journey, per leg and per cost centre, including partner and joint-venture shares.
  • The quirks, included: offline bookings made by phone and email, in-country payment gateways, subscription expenses and the other local realities are modelled so they arrive in the posting rather than in a spreadsheet beside it.
  • Nothing structural. The ledger, the hierarchy and the ERP's configuration are read, not rewritten.

When the feed is wrong

Built for an imperfect upstream.

Master data is maintained by people, and it is not always current: a profile is missing a grade, a budget has not been refreshed, a balance is a day behind. A travel platform that trusts the feed blindly either stops the traveller or pays the wrong amount, and the error surfaces weeks later in reconciliation, or in a claimant who has not been paid. UnityTrip is designed on the assumption that the upstream will sometimes be stale or wrong. Because every exchange with SAP is an event, a discrepancy carries its own trail back to the source record, so the correction is made once, at the source, and finance sees the problem when it happens rather than discovering it later. This matters because the layer that responds is also the layer where problems are reported first, including problems that began upstream; the trail is what shows where a fault actually started, so the fix goes to the system that owns it. What that looks like for a support team, including the case of a claim blocked by an upstream balance, is answered in questions from operations teams.

The same principle covers availability, and the boundary of responsibility is deliberate. If identity is down, nobody signs in anywhere, and that is tolerable because it is visibly not the travel platform's failure. If the ERP is down, travel still moves; postings wait and claims queue until it returns. What is not tolerable is the travel and logistics platform itself failing, because that is visible to every traveller on the day. An operation that runs everything through one system has all its eggs in one basket. The correction is not a bigger basket but the same eggs in more than one basket, right-sized per tenant and affordable at that size: fault-tolerant geo-replication for the travel platform, which a monolith on a single relational database cannot offer at a price a client would pay. The measure is the cost per guaranteed performant transaction, and because it is right-sized, a smaller operation can afford a workable answer and a larger one can specify exactly the resilience it needs.

Why travel runs above the ledger

Two different rates of change.

A ledger should change slowly and under control. Workforce travel changes constantly: a weather hold reorders a manifest, a rotation shifts, a policy group gains a new quota, a joint-venture partner starts sharing seats. When that complexity is pushed into the ERP, or into a standard travel product that cannot express it, it either waits for the next release cycle or leaks into spreadsheets, email approvals and exception queues around the system. The automation on paper and the process actually running diverge, and the cost lands in reconciliation rather than on the travel ledger. A workaround that someone maintains by hand every day is a requirement the software has not yet absorbed, and the model exists to absorb it.

UnityTrip absorbs that change where it belongs. A tenant's rules are configuration of the model, executed deterministically, so a new rule ships without a release project on either side. Because the platform is event-sourced and work is queued and streamed, a surge of activity does not contend with the ledger, and because the connection reads master data and writes governed postings, the ERP sees only outcomes it can journal.

The decision is therefore not whether to replace S/4HANA. It is whether travel complexity should live in the ledger or above it. The platform page explains why running travel on the wrong model makes every transaction cost more. The integrations page describes the SAP connection and the other systems UnityTrip connects to.

Questions buyers ask

Does UnityTrip replace SAP S/4HANA?

No. SAP S/4HANA remains the ERP that runs the operation and the system of record for maintenance, budgets, scheduling, procurement, HR and identity. UnityTrip is the operating layer for travel and fleet that sits above it: it takes staff profiles, budgets, currencies and balances from SAP each day, runs bookings, approvals, quotas and claims against that data, and returns postings for expense claims. The ledger is not duplicated and the ERP is not modified. SAP's travel product, Concur, is a separate system with its own comparison.

How does UnityTrip connect to SAP?

Over SAP RFC, personalised to each client's SAP configuration and bidirectional: staff profiles, budgets, currencies and balances flow from SAP into UnityTrip each day, and postings for approved expense claims and cost allocations flow back. The integration is in production today. Because UnityTrip is event-sourced, every exchange with SAP is recorded as an event with a full audit trail.

Why not run workforce travel inside the ERP?

An ERP is designed for a stable, governed ledger and changes on release cycles measured in months. Workforce travel is fast-changing and bursty, and runs on entitlement, quota, priority and displacement rules that a ledger is not built to express. UnityTrip absorbs that change as configuration of the tenant's model and posts only governed outcomes to SAP: for business bookings, no payment executes without an approved claim number.

What happens when the data from SAP is incomplete or wrong?

UnityTrip is designed on the assumption that upstream master data will sometimes be stale or incorrect. Every exchange with SAP is an event, so a discrepancy carries a trail back to the source record and can be corrected once, at the source, with finance seeing the problem when it occurs rather than in later reconciliation. Local realities a standard product cannot express, such as offline bookings, in-country payment gateways and subscription expenses, are modelled so they are included in the posting rather than left outside the system.

What stays in SAP and what moves to UnityTrip?

SAP keeps maintenance, scheduling, procurement, the general ledger, cost-centre hierarchy, budgets, HR master records and identity. UnityTrip takes on booking across owned, leased, chartered and commercial transport; travel policy execution; seat allocation, go-shows and manifests; budget approval at booking; and expense claims. Finance sees travel as governed data arriving in the ledger rather than as charges to be reconciled afterwards.

Tell us how your company moves people.

If your SAP landscape is settled and travel is the part that keeps changing, we should talk.

Talk to us

SAP, SAP S/4HANA and SAP HANA are trademarks of SAP SE. This page reflects UnityTrip's view based on publicly available information and is intended to help buyers assess fit. It is not endorsed by SAP. UnityTrip is not an SAP partner product.