How Veloq Cut Month-End Close by 80%

Veloq is a fictional mobility subscription company used throughout this template: it rents e-bikes and scooters to commuters on monthly plans in several European cities. By its fourth year, Veloq collected payments through three providers, settled in four currencies and closed its books in roughly two weeks every month. This sample case study follows how the finance and engineering teams consolidated onto one integration and one ledger, and how month-end close went from two weeks to two working days. All figures are illustrative.

The challenge

Veloq's payment stack had grown the way most do. The original card processor handled subscriptions. A second provider was added to support a popular local bank-transfer method in one market. A third arrived through a partnership that sold annual plans through employers. Each worked well on its own. Together they produced three settlement files in three formats, on three schedules, none of which referenced Veloq's own invoice numbers.

At month-end, a team of three analysts exported everything into a shared spreadsheet and matched payments to invoices by amount, date and customer name. The process had several recurring problems:

• Fees were netted differently by each provider, so the same plan produced three different settled amounts.

• Refunds and chargebacks arrived weeks after the original payment and often in a different file.

• Currency conversions happened at each provider's rate and time, making revenue in the reporting currency hard to verify.

• Nobody trusted the cash forecast, because unmatched items were carried forward rather than resolved.

We were not short of data. We had three versions of the truth and a spreadsheet trying to referee between them.

The approach

The team set one goal for the project: every payment, fee, refund and payout should exist in one place, linked to the invoice that caused it, on the day it happened. They worked through the four PAXORA layers in order rather than replacing everything at once.

One integration at the API layer

Engineering moved payment creation behind a single API, passing Veloq's invoice ID as a reference on every request. The existing providers stayed in place at first; only the entry point changed. That one field — the invoice reference travelling with the payment — did more for reconciliation than any later step.

Routing instead of hard-coded providers

With all payments flowing through one integration, routing rules decided which provider handled each one: local bank transfers to the provider that supported them, cards to the provider with the best approval rate for that card type, and failed payments retried on a second route where appropriate. Rules could be changed by the payments team without a deploy.

A single ledger at the settlement layer

Settlement files from every provider were ingested daily and posted to one ledger. Fees, refunds and disputes were recorded as their own entries rather than netted against payments, so each invoice showed its full history: charged, fee deducted, settled, refunded if relevant.

The rollout

The migration ran over a single quarter in three steps, chosen so that month-end close was never at risk:

1. Shadow mode. For one month, the new ledger ran alongside the spreadsheet. Analysts compared both and logged every difference.

2. Primary ledger. Once differences were explained, the ledger became the source of truth and the spreadsheet was retired for new transactions.

3. Provider consolidation. With routing in place, the employer-partnership provider was phased out and its volume moved to the remaining two, without any change to the customer experience.

The shadow month surfaced issues the team had not known about, including a recurring fee that one provider charged on refunds and a small but steady currency rounding difference. Both had been absorbed silently in the spreadsheet for years.

The outcome

Month-end close went from around ten working days to two in this illustrative example. More importantly, the remaining two days were spent reviewing, not matching. Most payments were matched automatically on the day they settled, and the exceptions queue was usually short enough to clear in an afternoon.

• Automatic match rate rose from a manual process to the large majority of transactions.

• Unmatched items older than thirty days fell to near zero.

• Analyst time shifted from reconciliation to forecasting and pricing analysis.

• Approval rates improved modestly as routing sent payments to the provider most likely to accept them.

What other teams can take from it

Veloq's experience is fictional, but the pattern is common. The biggest gains did not come from a new provider or a new feature. They came from three disciplined decisions: carry your own reference on every payment, record fees and refunds as separate entries, and run old and new systems side by side until the differences are explained. Teams that make those decisions early rarely need a reconciliation project later.

Sample case study for a website template — Veloq is a fictional company and all figures are illustrative.