Introducing the Alumio Route Builder
Now connect, orchestrate, and govern integrations at scale from one visual interface
The single deposit Stripe sends at the end of a payout cycle is split across the Sage X3 companies that actually earned it, so each set of books shows its own takings, its own fees and its own net.
Stripe pays out one net amount per currency, and Sage X3 keeps a separate set of books for every company and site a business runs. So the deposit that lands in the bank belongs to three companies at once, and somebody works out the split in a spreadsheet before anything is posted. Fees get lumped into one line nobody can explain, and the bank reconciliation waits on whoever built the file. The Stripe to Sage X3 integration does the split on the way through, so each company receives its own takings, its own fees and its own net amount as the payout settles.
DATA THAT FLOWS BETWEEN THEM
Payments
Refunds
Payouts
Processing fees
Customer invoices
Bank deposits
A Stripe payout is divided between the Sage X3 companies that earned it before anything posts, so no company ends up carrying takings that genuinely belong to another one.
Stripe processing fees arrive in Sage X3 as amounts of their own rather than buried inside a net deposit, so the cost of taking money is visible instead of quietly inferred.
What Stripe actually deposited and what Sage X3 was expecting are reconciled as the payout settles, so the bank statement is checked each month rather than rebuilt from scratch.
Adding a company in Sage X3 extends the split already in place rather than starting again, so a Stripe payout reaches the new set of books from the first day it trades.
When Stripe settles a payout, Alumio separates it into the amounts each Sage X3 company earned, posts the takings, the fees and the net to that company, and leaves nothing at all for anybody to allocate afterwards.
When a customer pays through Stripe, Alumio marks the matching Sage X3 invoice as settled in the company that raised it, so credit control chases what is genuinely outstanding rather than what merely looks outstanding.
When a refund is issued in Stripe, Alumio posts the reversal against the original document in Sage X3 and against the same company, so the reduction lands in the books where the sale was booked rather than centrally.
Alumio sits between sales channels and fulfillment systems as a governed integration backbone. Orders are routed, transformed, and validated, while status updates return to every channel.
Authenticate your systems using Alumio's pre-built connectors. Choose from 200+ connector packages in the marketplace, plus unlimited custom integrations.
Define how data fields map between systems in a visual interface. Adjust formats, enrich records, and apply business logic, no custom code required.
Configure flows to run in real time on events, on a schedule, or both. Reduce manual data entry and let Alumio handle movement and transformation between systems.
.svg){kind=icon}
Once your first integration is live, adding your ERP, PIM, WMS, or CRM connects to the same hub. Existing flows keep running. No rebuilding from scratch.
The connection worth making next is usually the tool that chases what never arrived, because Stripe tells you a payment failed and Sage X3 tells you an invoice is open, and neither one does anything about it. A collections tool reads both and works the list. Alumio holds that connection alongside this one, so a chase starts from the amount actually outstanding rather than from a report somebody exported on Monday.
Yes, and whether a payment travels on its own or inside a settlement is the choice to make early. Alumio can post each Stripe payment as it clears so an invoice is marked paid the same day, and post the payout separately with its fees and its net, so the bank deposit reconciles in Sage X3 as one entry. Most finance teams run both, because the two answer different questions. Both depend on what Sage X3 offers over its own interface.
No, this is configured rather than coded. What goes away is the monthly spreadsheet that turns one Stripe deposit into a set of Sage X3 entries, and the accountant who is the only person able to rebuild it. The split rules and the accounts each amount posts to are set up once and reused. Where a company applies its own rounding convention that configuration cannot express, the Code Transformer carries that calculation.
In each company, split by what that company earned, rather than in whichever one holds the bank account. Stripe settles by account and currency while Sage X3 keeps books per company, so posting the whole deposit to one and journalling the rest across later is what creates intercompany entries nobody planned. Deciding the split rule first, then letting it run on every payout, keeps each set of books standing on its own.
Alumio records the Stripe payout reference beside every Sage X3 entry it produced, which is what makes the awkward case findable. A deposit that will not agree with the ledger because the two put a different rate on it reads as a rounding argument rather than a fault, so it raises an alert live with both figures and the reason behind it. Retries run where configured, so nothing is left unreconciled.
Talk to an Alumio integration specialist. We'll map the right architecture for your systems, at the right scale, so your operations stay reliable through every change.
.svg)
