Introducing the Alumio Route Builder
Now connect, orchestrate, and govern integrations at scale from one visual interface
A shopper who sends a Shopify order back leaves Enova 365 needing a correcting document rather than a negative line, and that correction is raised against the original sale as the refund is made.
Polish accounting does not treat a return as a smaller sale. Enova 365 expects a correcting document that points at the original invoice, carries its own numbering and lands in the period the correction belongs to, and none of that arrives with a Shopify refund. So somebody raises each one by hand, matches it to a sale from an order number in a message, and a busy January leaves a backlog that only surfaces when the period will not close. The Shopify to Enova 365 integration raises the correction as the refund is made, against the document it corrects.
DATA THAT FLOWS BETWEEN THEM
Orders
Sales invoices
Refunds
Correcting documents
Customers
VAT rates
A Shopify refund raises a correcting document in Enova 365 that points at the original invoice, so the books show a correction rather than a sale with a minus in front of it.
Because the correction is raised as the Shopify refund happens, Enova 365 receives it inside the period it belongs to and a closed month does not have to be reopened.
The rate applied on the original Shopify sale travels onto the correction, so what is reported through Enova 365 reflects the money the business has actually kept.
Returns are documented as they arrive rather than in a pile after the season, so the Enova 365 close is a review instead of a week of matching refunds to sales.
When a refund is issued in Shopify, Alumio raises the correcting document in Enova 365 against the invoice it relates to, so the reduction is tied to a specific sale rather than posted as an amount somebody investigates later.
A shopper returns one line of a Shopify order and Alumio corrects only that line in Enova 365, so the remaining goods stay invoiced and nobody cancels an entire document just to deal with a single item coming back.
Alumio reaches Enova 365 through the interface it makes available and creates the sales document each paid Shopify order becomes, so the shop and the books describe the same trading without anybody keying it in twice.
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.
A return is not finished when the money goes back, which is where the next connection usually goes. The warehouse decides whether the goods can be sold again, and until that is known Shopify is offering stock nobody has checked and Enova 365 has corrected a sale for an item sitting in a box. Alumio holds that connection alongside this one, so the decision reaches both.
Yes, and the two are deliberately different flows. A paid Shopify order becomes a sales document in Enova 365 as it completes, while a refund raises a correction pointed at that document rather than a second sale. Keeping them separate is what lets the correction carry the original reference, which is the part that makes it findable when somebody asks about it in March.
No, this is configured rather than coded. The routine it removes is a person raising each correcting document by hand, finding the original from an order number in an email, and hoping the period is still open. Which Shopify event creates which Enova 365 document is set up once in Alumio. Where a business uses its own document series that mapping cannot express, the Code Transformer handles that step.
In place, with a correction attached to it, which is the point of doing it this way. Enova 365 keeps the original sales document and records the correction against it, so the history shows what was sold and what came back rather than a single amended figure. That matters when somebody asks about a specific Shopify order months later, because the answer is on one page instead of reconstructed from two entries that happen to be near each other.
A refund recorded without the document it corrects is the failure to catch, because the money has genuinely left and only the paperwork is missing. Alumio watches each transfer live and records the Shopify refund with the Enova 365 invoice it was pointed at, so a correction that cannot be matched raises an immediate alert naming both and the reason. Retries run where configured, so nothing is left unrecorded.
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)
