Which system leads? Interfaces for payroll, POS and payment providers

At month-end, three files land on your desk: the payroll journal from the payroll system, the daily closings from the point of sale (POS), and the statement from the payment service provider. One amount in accounting doesn't match, and nobody can say which figure is correct. Each department points to its own system. That means follow-up questions, duplicate corrections and postings that have to be reopened later. The cause is almost never the interface itself. It is the unresolved question of which system is the leading one for which data.

The Case: One Correction, Two Truths

An employee changes cost centers. The HR department updates it in the payroll system, while Controlling updates it in the ERP (Enterprise Resource Planning) system. In the next payroll journal, the old cost center is back, because the import overwrites the data with that of the payroll system.

This is data ownership: for each data type, exactly one system may accept changes. All other systems only read. If there are two places where a value may be changed, the wrong one will eventually win.

Check question: Where would you change this value today, and would the change still be there after the next data run?

Step 1: List Your Data Types

For each specialist system, note which data types originate there. Use one line per data type:

1. Employee master data, wage types, payroll journal
2. Item master, prices, sales data from the POS or ticket terminals
3. Payments, fees and payouts from the payment service provider
4. Customers, suppliers, invoices
5. Vehicles, assets, maintenance objects, if you manage them
6. Inventory and product data, if a shop is connected

Add only data types that actually move between systems. A field that exists in only one system needs no decision.

Step 2: Define Exactly One Leading System per Data Type

A business with payroll, a POS and a payment service provider can apply these rules of thumb:

• Payroll: The payroll system leads for employees, wage types and payroll processing. The ERP receives the result, for example the monthly payroll journal, and posts it. In one project, Simplify-ERP transfers the payroll journal from a SAP text export to Odoo. The direction stays one-way.
• POS and terminals: The POS leads for the individual sale. The ERP leads for the item master and delivers it to the POS. Two data types, two directions. That is fine as long as each one is unambiguous on its own.
• Payment service provider: It leads for what was actually paid, withheld and paid out. The ERP leads for what was invoiced. You reconcile the two sides; neither overwrites the other. In one project, sales data from ticket terminals and statements from the payment service provider are provided and posted in Odoo.
• Master record as anchor: When several objects refer to the same thing, that thing needs a master record. In a business with a vehicle fleet, the vehicle is the master record; asset, maintenance object and cost center refer to it instead of copying it.

Decision rule: Does the system where the data originates first, and where it is functionally owned, lead? If so, it stays the leading system. If not, document in writing why another system should lead.

Step 3: Define the Direction and the Path

For each relationship between two systems, define which way the data flows and how.

File or API? If the data flows once per period and nobody needs it in between, a file is enough, such as an export with a fixed format. One example is the export profiles used to send accounting data to the Austrian software BMD. If inventory, orders or payments need to be accurate in both systems in near real time, you need an API (application programming interface), through which systems exchange individual records.

Two-way case, the shop: With a shop connection, the ERP usually leads for product data, while the shop leads for the order. Products go from Odoo to the shop, while orders and contacts come back. With several shops, there must still be a single leading product system. This is consistent with a shared channel core that binds several connectors to one Odoo.

Check question: Is there a data type that flows in both directions? If so, define field by field which side wins.

Step 4: Draw the Map

Draw a sheet with one box per system. Label each box with the data types for which it leads. Draw arrows in the direction of flow and write on them: file or API, rhythm, and who is responsible when errors occur.

Check the map against these cases:

• Enterprise-wide search: If a search runs across all Odoo data, it only reads. It must not write anything back. A data store alongside the ERP, such as the Odoo DataLake with its continuous synchronization, appears on the map as a read target, not as a leading system.
• No-code AI automation: An agent that processes documents or answers customer inquiries writes data. Record which system and which field it writes to, and whether a person confirms the result beforehand.
• Shop connection: See above: product leading in the ERP, order leading in the shop.
• Version upgrade: Every interface that writes to or reads from Odoo must be retested after an upgrade. The map shows which ones those are.
• Solar PV business: If sales, projects, warehouse and accounting run in one software, the interfaces between them disappear. You then only need to check the external boundaries, such as those to the payment service provider or to payroll.

Step 5: Reconcile Discrepancies Regularly

A map prevents disputes, but not errors. Define when you compare the systems. One example is the monthly reconciliation of a data import against the trial balance. Here you compare the totals from the import with the balances in the general ledger. If a total deviates, look for the cause in the source system and correct it there, not in the ERP.

For postings, the rule is: do not overwrite posted documents with a repeated import. A dry run that writes nothing shows beforehand what an import would change.

Your Next Step

Today, take a data type that recently caused a dispute over the right figure, for example cost center, item price or payout amount. Write down three things: Which system leads it? Where does it flow? Who corrects it when errors occur? If you cannot answer all three questions with one name each, you have found the first gap on your map.