Automated Revenue Reconciliation for a Robotaxi Business at Scale
Case Study · Autonomous Mobility & MaaS
Automated Revenue Reconciliation for a Robotaxi Business at Scale
Industry
Autonomous Mobility & MaaS
Size
~2,500 employees
Region
North America
Monetization Model
Transaction-Based (Per Ride)
About Customer
Use case
Automate Ride-to-Revenue Reconciliation and Financial Reporting
Transformation
Manual Reconciliation → Automated 3-Way Revenue Match
Live since
2024
Company
A self-driving technology company and subsidiary of one of the world’s largest technology conglomerates. Operating a fully commercialized autonomous robotaxi service across multiple US cities, the company handles millions of rides with no human driver — and needs a financial infrastructure that can match the precision of its autonomous systems.
Situation
The company had built a best-in-class autonomous driving platform — but the financial infrastructure beneath it had not kept pace. Ride data, payment captures, and bank settlements flowed through separate systems with no automated reconciliation layer connecting them. As transaction volumes grew with each new city expansion, the gap between operational data and auditable financial records became increasingly difficult to manage.
The business needed a financial backbone that could match its operational growth — and support future expansions into subscription billing, B2B mobility packages, and specialized industry use cases such as healthcare patient transport validation.
Challenges
- Ride data, payment captures, and bank settlements arrived through separate systems with no automated matching. Reconciliation required manual effort that grew linearly with transaction volume — unsustainable as the company expanded to more cities.
- Without a unified, auditable pipeline from ride event to financial ledger, revenue reporting carried inherent risk. Growing discrepancies between operational data and financial records were becoming harder to explain and defend.
- The existing architecture had been built for current operations — not for the commercial model expansion the business needed. Supporting subscription billing, B2B mobility packages, and healthcare integrations required a more flexible financial foundation.
- A public cloud architecture was non-negotiable. The solution had to fit the company’s infrastructure strategy without requiring on-premise components or bespoke hosting.
Why DigitalRoute
Manual vs. automated – fragmented ride data and manual matching replaced with a public-cloud ride-to-revenue pipeline
The company needed to replace Mulesoft with something that could enforce completeness validation before any transaction touched the accounting ledger — not just route events, but guarantee that every reservation was matched to a payment before posting. That is a fundamentally different architectural requirement from generic integration.
- Purpose-built for financial-grade data quality. DigitalRoute was selected specifically because it could enforce completeness validation before posting. Every transaction reaching S/4HANA has been validated and correlated — not what Mulesoft was designed to do.
- 1-year correlation window at 1.5 billion events. Reservations and payments arrive asynchronously — sometimes months apart. The ability to hold and match events across a 1-year window at this volume was a non-negotiable requirement no generic integration tool could satisfy.
- Native SAP S/4HANA integration. With SAP MaxAttention involved in the blueprint phase, DigitalRoute’s native integration with SAP Convergent Invoicing, FICA, and HANA removed integration risk at the most critical point in the transformation.
The Solution
Mediation and data quality layer between the ride operations platform and SAP S/4HANA Cloud FI-CA
Working with SAP, the company deployed DigitalRoute UsageCloud as the mediation layer between its ride operations platform and SAP S/4HANA Cloud. Every ride event — regardless of whether it originated from the company’s own app or through a partner ride-hailing integration — is ingested, enriched with reference data, validated, deduplicated, and converted into Billable Items before reaching SAP.
The 3-way match that finance required — reconciling ride billable items, payment confirmations from the payment gateway, and bank settlement reports from SAP Digital Payments — is now automated in SAP FI-CA. Revenue is recognized accurately at transaction level, with a complete audit trail from ride event to ledger entry.
The architecture was designed from the start to support future commercial expansion. With subscription billing and B2B mobility packages already in scope for future phases, the mediation layer serves as a reusable foundation — not a component that needs to be rebuilt for each new business model.
The Outcome
Automated ride-to-revenue pipeline
Ride purchases and payment data now flow automatically from the operations platform to the financial ledger — replacing manual reconciliation with an auditable, scalable process.
3-way financial match, transaction by transaction
Every ride is matched to its payment confirmation and bank settlement in SAP FI-CA — giving finance an accurate, defensible view of revenue at transaction level.
Future-ready for new business models
The mediation architecture is designed to support future commercial models — including subscription billing and B2B mobility packages — without requiring a rebuild of the financial foundation.
The Architecture
Facing a similar challenge?
Talk to us for a walkthrough of how this transformation was done and what it could look like for your business.