Introducing the Alumio Route Builder
Now connect, orchestrate, and govern integrations at scale from one visual interface
The payout that reaches the bank is the sale minus a set of things the marketplace decided on, and SAP Business One needs all three of those rather than merely the number that arrived.
A marketplace does not pay you what the customer paid. It takes its commission, its fulfilment charges and whatever else applies, and sends the difference, so the money arriving in the bank matches no order in the system. The usual repair is a spreadsheet at month end where somebody works backwards from the payout to the sales it covers and books the gap as one lump called fees. Connecting ChannelEngine and SAP Business One lets the sale, the commission and the net arrive as three separate facts, so the ledger holds what actually happened rather than the residue of it.
DATA THAT FLOWS BETWEEN THEM
Orders
Order lines
Commission
Payouts
Customers
Returns
Commission and fulfilment charges reach SAP Business One as their own amounts rather than as a difference somebody books at month end and labels fees for want of a better word.
A payout is joined to the orders it covers as it arrives, so nobody is working backwards from a bank line to a week of marketplace trading with a calculator and a spreadsheet.
Because what each channel charged is separate from what it sold, the question of which marketplace is actually worth trading on has an answer in the ledger rather than an opinion.
A refund reaches SAP Business One against the sale it reverses rather than as a deduction inside the next payout, which is where returns usually disappear from anybody's view.
When ChannelEngine reports a payout, Alumio posts the sales, the commission and the net separately in SAP Business One, so the bank line and the ledger agree without somebody reconstructing the arithmetic afterwards.
When a marketplace order arrives without a customer SAP Business One recognises, Alumio resolves it against the rule you set rather than creating one for every buyer, so the ledger does not fill with names nobody sees twice.
When a return is deducted from a payout, it reaches the sale that it reverses rather than quietly reducing the total, so the margin on that order reflects the fact that the goods came back into the warehouse again.
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.
Marketplace returns are handled by a service the channel obliges you to use, and neither of these systems sees it. A return that was graded and resold is a different outcome from one written off, and channel margin is wrong until that distinction reaches the ledger. Alumio holds that connection alongside this one so the picture is complete rather than nearly complete.
Yes, and orders and payouts are worth treating as separate arrivals rather than one. An order is known when it is placed and the money follows days or weeks later, so forcing them into one step means the ledger waits. Alumio posts each on its own cycle, and what can be created is whatever SAP Business One exposes for it.
No. What the configuration actually holds is which marketplace charge maps to which account and which customer a channel order posts against, and those are decisions the finance team makes once and can see afterwards. Where a channel reports a charge in a form the ledger has no account for, the Code Transformer resolves it at that one step.
Wherever finance decides, which is the point of separating them at all. A payout arriving as one figure gives the ledger a number and no explanation, and the commission on a sale is a cost of selling rather than a discount on the price. Posting the gross sale and the charge separately means margin, VAT treatment and channel comparison all work without anybody unpicking a bank line first.
The one that stalls a month end is a payout that matched no order, because the money is real and the sales behind it are not identified. Alumio names what could not be matched and to what, so the search is one payout rather than a week of trading. Each transfer is monitored live and logged with what it carried, a refusal alerts with the reason, retries run where configured, and nothing is lost silently.
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)
