In our reviews, the control weaknesses that matter most are rarely sophisticated. They come down to one person being able to do two things that should have been done by two people: add a supplier and pay it, or receive cash and record the receipt. Segregation of duties is one of the oldest internal controls there is, and in an ERP it is also one of the easiest to undo with a single change in the user settings.

What is segregation of duties?

The principle is that no single person should control every stage of a transaction. Control frameworks split a transaction into four functions: authorising it, recording it, having custody of the asset involved, and reconciling the records to reality. When one person holds two of those functions, they can both create an error and hide it. The aim is not distrust of any individual. It is a design in which a mistake, or a deliberate misstatement, has to pass through a second pair of hands.

Which pairs of duties conflict?

  • Creating or changing a vendor, including its bank account, and approving or releasing payments to vendors.
  • Raising a purchase order and receiving the goods against it, or approving the vendor bill for the same order.
  • Creating customers and setting credit limits, and approving sales on credit or issuing credit notes.
  • Receiving cash or customer payments, and posting the receipts or reconciling the bank account.
  • Posting manual journal entries, and approving them or changing the lock dates that protect closed periods.
  • Administering user access in the system, and processing financial transactions in it.
  • Adjusting inventory quantities, and counting or valuing the same stock.

How do you implement it in Odoo?

Odoo controls what a user can do through access groups assigned per application. In Accounting the levels run from invoicing-only access up to full accounting and administrator rights; Purchase, Sales and Inventory each have their own user and administrator levels. The exact group names and what each one allows vary by version and edition, which is why we confirm the version before we design the matrix. The practical sequence is the same on every implementation.

  • Start from the process, not the system: list who does what in purchasing, sales, treasury, inventory and the close, and mark the conflicting pairs.
  • Translate the result into a role matrix, then into Odoo access groups, giving each user the lowest level that lets them do their job.
  • Add approval steps where one role must check another: Purchase offers a two-step order approval above an amount you set, and further approvals on payments or entries can be added with Odoo’s approval features, depending on edition.
  • Protect closed periods with lock dates, and restrict who can change them.
  • Remove administrator rights from anyone who processes transactions, and keep a separate, rarely used administrator account.
  • Review the user list and group assignments at least quarterly; access drifts every time someone covers for a colleague on leave.

This is part of how MFT designs an Odoo implementation: the access matrix is signed off by the finance lead before users are created, so the system starts with the separation built in instead of having it retrofitted after the first audit.

What if the team is too small to split duties?

A finance team of two cannot separate seven pairs of duties. That does not make the principle irrelevant. It means compensating controls: checks performed by someone outside the transaction, usually the owner or general manager, that would detect what segregation would have prevented.

  • The owner approves every new vendor and every change to vendor bank details, from a report of changes to vendor records.
  • Bank statements reach the owner directly, and the owner reviews and signs the monthly reconciliation.
  • A monthly list of manual journal entries, credit notes and inventory adjustments is reviewed by someone who did not post them.
  • Payments above a set amount need a second approver, even if that person sits outside finance.

Segregation of duties is not about trusting people less. It is about not asking anyone to be the only control.

How do you know it is working?

Test it. Export the users and their groups from Odoo and compare them with the approved matrix. Select vendor changes and check who made them and who approved them. Look for anyone who posted and approved the same entry. An internal audit review of access is short when the design is sound, and it is the only way to know the design survived the last year of staff changes.

Talk to MFT about this