Introducing the Alumio Route Builder
Now connect, orchestrate, and govern integrations at scale from one visual interface
Unit4 receives a Shopify sale with the activity it belongs to already attached, so income is reportable the day it arrives rather than after somebody has been through the order numbers.
An organisation running Unit4 does not book income the way a retailer does. Money arrives against an activity, a project or a funder, and a figure with no activity against it is income the finance team cannot report on and the funder will not recognise as its own. A Shopify sale knows what was bought and nothing about which activity it supports, so the coding is added afterwards by somebody reading order numbers. Connecting Shopify and Unit4 decides the activity when the sale happens, so income arrives already attached to the thing it paid for.
DATA THAT FLOWS BETWEEN THEM
Orders
Order lines
Customers
Activity codes
Funding sources
Posted income
A Shopify sale reaches Unit4 with an activity against it, so the figure counts towards something from the moment it lands rather than waiting in a holding account.
A return to a funder is assembled from figures that were already coded, so the month the return covers is not also the month somebody spends reconstructing what the income was for.
Which activities exist and how they are structured is the organisation's own decision, and the connection carries that structure rather than proposing one of its own.
Because the activity is decided by a rule rather than a person, a week of unusual volume does not produce a backlog of Shopify sales nobody has had time to attribute.
When a supporter buys through Shopify, Alumio resolves the activity from what was bought and posts the income to Unit4 against it, so the figure is attributable on arrival without anybody opening the order to work it out.
When the organisation takes on work that is funded separately, the products belonging to it are pointed at the new activity, so income starts arriving coded from the first sale rather than from the first quarterly review.
When an order cannot be resolved to a Unit4 activity, it is held and named rather than posted to a default, so the exception reaches a person while it is still small instead of surfacing inside a funder return.
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 moment a public buyer orders through a tender or framework portal, that becomes the next one. The order arrives with contract references the shop has never seen and the finance team needs both. Alumio holds that connection alongside this one and reuses the activity coding already agreed, so an order from a framework and an order from the shop are reportable in the same terms.
Yes, with the activity code carried on the line rather than added to the header afterwards. Alumio posts each Shopify sale to Unit4 on the schedule you set, with the coding resolved before anything is written, so the entry is complete when it arrives. What can be posted that way is whatever Unit4 exposes for it.
No. There are two ways this is usually done: finance codes web income by hand each month, or it goes to a single catch-all and is analysed never. The configured route replaces both, because which Shopify value points at which Unit4 activity is an entry somebody in finance can read and change. Where the rule depends on something configuration cannot phrase, the Code Transformer covers that step.
The organisation does, and that is worth saying plainly because the code structure belongs to the institution rather than to any system. What the connection does is apply the decision consistently: a product, a category or a shipping condition points at an activity, and every sale follows the rule. Changing the rule is a change in one place, which matters most when a funding arrangement ends mid-year.
The quiet failure is a sale posted without the activity it funded, because it reconciles perfectly and reports as nothing. Alumio names the code that was missing and where the entry stopped, so the gap is visible before a return is prepared. Each transfer is monitored live and logged with the order it carried, a refusal alerts with the reason, retries run where configured, and nothing is lost without a record.
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)
