03.3Success story · Financial services
Financial Service Plus
A core system that no longer blocks.
The factoring processes ran on an outdated core system: every new requirement cost more than the last, new tenants were barely representable. We rebuilt the core product as a multi-tenant platform — during live business.
Core system
One model
Processes, roles and reporting in one model instead of copies per client.
Operation
No standstill
Replacement in stages, with real process volume in daily business.
Application views are adaptations in the Lipsia design system · all figures illustrative
01About the project
The core system was the limit of the business.
Financial Service Plus runs factoring: buying receivables, checking them, paying out, monitoring. That business ran on a core system grown over years — operational, but at its end. Technical debt limited not the technology but product development.
We rebuilt the core product and scoped it for tenants: processes, roles and reporting live in one model, differences between tenants are configuration. The legacy system was replaced in stages, without stopping the factoring business.
02The task
Rebuild without stopping.
A core system in finance cannot have a gap: booking day, audit trail and payout keep running while the platform underneath is exchanged. The task was therefore not only architecture but sequence.
- Rebuild the core product as a platform
- Take on new tenants without special cases
- Map the factoring chain close to the process
- Bring reporting into the core instead of calculating beside it
- Replace the legacy system in stages
03Tenant model
One model instead of copies per client.
In the legacy system every tenant was a branch in the code — each change had to be thought through and tested several times. In the new platform the tenant is a record with parameters: process variant, assignment type, payout rule, dunning levels.
Difference
Configuration
What separates tenants is a parameter — not a branch of its own in the core.
Limits and usage in the core
Purchase limits per debtor, their usage and any breach belong in the core system — not in a side calculation somebody maintains. Checks then work on the same state as reporting.
Limits and usage live in the core system, not in a side calculation.
Check
One state
Limit check and reporting calculate on the same basis.
Reporting without a second system
Volume, balances and due dates per tenant live in the core system. That replaces the detour through exports and spreadsheets the legacy system required.
Reporting lives in the core system — no export, no side calculation.
Source
1
One data base for processing and reporting.
04Purchase and review
The chain as the department counts it.
Purchase, review, payout, collection: the platform maps the stages the way back office counts them — with balances, rules and an audit trail that makes every step traceable.
Batch
126 items
An invoice batch with a status per item — review cases are visible, not searched for.
Rules
5
Rules per item: master data, duplicate, limit, assignment, release.
Rules are part of the process
Every item passes the same rules, and the rule that holds is shown on the case. What back office decides stays a decision — what is a rule is not re-discussed each time.
Batch 2026-03-14-A · 126 items
Boundary
Limit 94 %
The rule stops the item, back office decides on the release.
An audit trail instead of reconstruction
Receipt, master data match, triggered rule, submission for release: the history sits on the document. That is the basis for audit and revision — and for questions that arrive three months later.
Every step is traceable — a precondition for audit and revision.
Evidence
Every step
Time, trigger and rule stay with the case.
05Replacement
Staged replacement, no standstill.
The legacy system was not switched off but relieved module by module: first the chain, then reporting, then the tenants. Every stage was productive in itself — the big bang such projects like to promise was never part of the plan.
Sequence
Stage by stage
Every stage goes live before the next one starts.
Illustrative balances in the application pattern · no client data
06Technical facts
What this system is made of.
Scope details from our own project communication.
- Platform
- Multi-tenant process platform
- Business processes
- Purchase · review · payout · collection
- Tenant model
- Process variants as configuration
- Rules
- Rules per item with an audit trail
- Reporting
- In the core system, no second system
- Replacement
- Staged replacement of the legacy system
- Lipsia's role
- Architecture · engineering
07Outcome
A platform that allows product work again.
The core product runs on a newly built, multi-tenant platform. Further product modules are planned; which come first is a business decision, not an architectural one.
Confirmed
- Rebuild of the core system
- Multi-tenant platform for the core product
- Processes, roles and reporting in one model
- Architecture and engineering by Lipsia Digital
//Next story
Storefront
A shop system more than ten years old, replaced by a modern storefront — with AI in the engineering process.
//Read on
Let's talk about your project.
A free orientation call: your situation, your plans and mutual fit clarified. You decide on the next step afterwards.