Introducing the Alumio Route Builder
Now connect, orchestrate, and govern integrations at scale from one visual interface
A counted drawer and the takings Odoo POS expected arrive in Exact Globe together, so the difference between them is booked deliberately instead of being absorbed by whoever closes the day.
Closing a session on Odoo POS produces two numbers: what the till says should be there and what somebody counted. They rarely match, and the difference is a real amount that has to end up somewhere in Exact Globe. Left unconnected, it is handled by whoever is on shift, which means it is written off, held in a drawer, or entered against whatever account looks plausible. At year end nobody can say whether a pattern of small shortages was theft, miskeying or a broken float. Connecting Exact Globe and Odoo POS books the expected takings, the counted amount and the difference as what they are.
DATA THAT FLOWS BETWEEN THEM
Session totals
Counted cash
Cash differences
Payment methods
Journal entries
Store accounts
Both the expected and the counted figure from an Odoo POS session reach Exact Globe, so the difference between them is posted rather than quietly rounded away by a manager.
Payment methods are separated on the way through, so cash, card and voucher takings land in the accounts they belong to and a shortage in one is not hidden by a surplus in another.
Because every session posts the same way, a run of small shortages at one store becomes visible in Exact Globe instead of something a district manager happens to mention.
The person closing the till stops making an accounting decision at eleven at night, which is the point at which the least reliable entries in the ledger have always been made.
When an Odoo POS session closes, Alumio reads the expected total, the counted amount and each payment method and writes the journal entry into Exact Globe, so the day's takings are booked without anybody keying a summary.
Differences are posted to the account you nominate per store, so Exact Globe holds a running record of shortages and surpluses by location and the question of whether one till is unusual can be answered from the ledger.
Alumio connects to Odoo POS through its available API, as it would any reachable system, so voucher redemptions come across separately from cash and settle against the liability they reduce rather than as new revenue.
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.
What the ledger is still missing at year end is the better guide than what looks connectable. For most retailers it is the outstanding voucher and gift card balance, which is a liability that grows quietly and lives in the platform that issued it rather than in Exact Globe or Odoo POS. Alumio holds that connection alongside this one, so what has been sold and not yet redeemed is a figure finance can see rather than estimate.
What has to balance is settled first, and then each session posts on its own. Alumio reads the closing figures from an Odoo POS session, the expected total, the counted cash and the split by payment method, and writes them into Exact Globe as one entry with the difference on its own line. Nothing is netted off on the way through, because a difference that has been absorbed cannot be investigated later.
No, and month end is the test of whether it was set up properly rather than the day it goes live. Which Exact Globe accounts receive Odoo POS takings, differences and each payment type are settings in Alumio, so a new store or a new payment method is a configuration change. Where a business has an unusual float or handover arrangement, custom logic remains available through the Code Transformer for that one rule.
On the account you nominate for it, which is the decision this integration forces into the open. An Odoo POS session close produces an expected figure and a counted one, and the gap is money that has already left or arrived, so Exact Globe has to receive it as an entry rather than as a rounding. Posting it per store and per session is what turns a run of small differences into something anybody can look at.
The difference has to land somewhere, and if the entry does not reach Exact Globe it lands on the person who closed the Odoo POS session. Alumio monitors each posting in real time and logs the session it read, so an entry Exact Globe refuses, often a closed period or an account that does not exist for that store, raises an immediate alert with the reason. Retries run where configured and the session stays flagged, so no day's takings sit outside the ledger without anyone knowing.
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)
