Access rights and internal controls in Odoo for Egyptian companies

Executive summary

• Access control in Odoo 19.0 (odoo.com/documentation/19.0) has two layers: a role set on a user when added (Administrator or User internally, Portal or Public externally), and a per-app group level whose options vary by app, the most common being Blank/None, User: Own Documents, User: All Documents and Administrator.
• Accounting has its own field, labelled Accounting in 19.0 (Invoicing in 18.0), with levels set by the app itself: in the 19.0 code they run from Invoicing (invoices, payments and basic invoice reporting) to Administrator (full access, including configuration).
• Multi-company access is set by the Companies and Default Company fields on the user form; products and contacts stay shared across companies unless a Company field is set on them.
• Segregating vendor creation, bill approval and payment registration rests largely on a sequence of states (draft, posted, paid) and on specific controls, since one Invoicing level covers both bills and payments; purchase orders have a built-in approval above a minimum amount, and a threshold on any other button needs Studio's Approval rules.
• The accounting Audit Trail logs every change to a field with accounting impact, with its date, user and old and new values; its restrictive mode blocks deleting tracked records outright.
• The documented lock dates act differently (Lock Everything, Lock Tax Return and an irreversible Hard Lock); a posted entry is corrected by reversing it or resetting it to draft after lifting the lock, not by deleting it.

Roles and per-app groups

Adding a user from Settings ‣ Users ‣ Manage Users sets one of the four roles the 19.0 documentation lists: Administrator, described as "an internal user with access to technical features, product creation, export, and other advanced permissions"; User, with less access; Portal, for a customer or vendor who only sees their own data; and Public, for a website visitor (20.0, released in September 2026, adds a third internal role, Light, with no access to apps such as Purchase or Accounting). On top of the role, each app has its own group, chosen on the Access Rights tab from a drop-down whose options "vary for each section", the most common being "Blank/None, User: Own Documents, User: All Documents, or Administrator." Accounting does not follow that scale. Its field, labelled Accounting in 19.0 (Invoicing in 18.0), carries levels defined by the app itself: in the 19.0 code the entry level is Invoicing, "Invoices, payments and basic invoice reporting", and the top level is Administrator, "Full access, including configuration rights" — the level the documentation tells a company to give its accountant.

Creating a new vendor or customer is not part of any Accounting level: it sits on Contact: Creation, under Master Data, and in the 19.0 code also comes with the Administrator level of Purchase, Sales or Inventory. Changing another user's permissions needs its own permission (Administration set to Settings or Access Rights), since "only an administrator can change access rights"; Superuser mode bypasses every access right and record rule at once, and the documentation warns it "should be exercised with extreme caution."

Each user's Security tab lists the devices they have logged in from, the profile keeps login details such as the IP address, and the documentation recommends checking them "periodically, to ensure all access is from the user, and no one else has accessed the database" — access rights are not a one-time setting at hiring.

Access across multiple companies

In a database with more than one company, the Companies and Default Company fields on the Access Rights tab control access: the first sets which companies a user can reach, the second which one opens by default. Records such as products and contacts stay shared across all companies unless their Company field is set, at which point they are visible only to users logged into that company. Inter-Company Transactions automatically create the matching vendor bill, sales order or purchase order, and synchronise stock moves, between two companies in the same database — and the Validated option validates each counterpart document without review.

Segregating vendor creation, bill approval and payment

Odoo's standard levels do not separate every step of the purchase cycle: the Invoicing level covers bills and payments alike, so the separation runs largely through a sequence of states and specific controls. A vendor bill is created as a draft, and once confirmed, "the status changes to Posted... once confirmed, a vendor bill can no longer be updated"; payment is then registered as a separate action, by clicking Pay. Each product's Control Policy sets the billing basis: On ordered quantities builds the draft bill as soon as the purchase order is confirmed, while On received quantities waits until part of the quantity has been received. With 3-way matching enabled, each bill carries a Should Be Paid field (Yes/No/Exception), meant to ensure a bill is paid only once some or all of the ordered products have been received; a draft bill that is changed is set to Exception, but Odoo "does not block the changes", and the field can be changed by hand. On each vendor, the Auto-post bills field automates confirmation itself, between Always, Ask after 3 validations without edits, and Never — Always posts that vendor's bills created automatically, by email or PDF upload, without anyone confirming them.

Purchase orders have a built-in amount limit: the Purchase Order Approval setting in the Purchase app, with its Minimum Amount, sends any order at or above that amount to To Approve unless a Purchase Administrator confirms it. The setting is present in the 19.0 code, although the 19.0 documentation, unlike 13.0's, no longer describes it. For any other button, such as confirming a bill, the tool the 19.0 documentation gives is Studio's Approval rules. A rule names Approvers or an Approver Group and an optional condition restricting when approval is required; several steps can be chained, and Exclusive Approval stops one user approving more than one step on the same record; every decision is logged in the record's chatter.

The audit trail and what cannot be deleted

Accounting ‣ Review ‣ Audit Trail displays a report that "tracks changes made to fields that have an impact on accounting," with the date, user, and old and new value of each change. Restrictive Audit Trail (under Accounting ‣ Configuration ‣ Settings, Reporting section) blocks deleting any tracked record outright; cancelling or archiving is all that remains.

Separately, another mechanism secures posted entries by hashing: enabling Secure Posted Entries with Hash on a journal gives every entry posted in it a SHA-256 fingerprint of its essential data, chained to the fingerprint before it so that inserting an entry later breaks the chain. The warning here has no exception at all: "once you post an entry in a restricted journal, you cannot disable the feature anymore, nor edit any secured entry" — unlike the lock dates below, of which only the Hard Lock admits no exception.

Lock dates and drafts left open

Lock dates are set from Accounting ‣ Accounting ‣ Lock Dates. The 19.0 documentation describes three, with different effects:

The 19.0 code also defines a sales and a purchase lock date, which postpone entries of their own type in the same way; the documentation does not cover them.

A posted entry cannot be deleted as it stands. It is corrected by one of two actions: Reverse Entry offsets it with a counter-entry, or Reset to Draft returns it to draft to be edited and reposted. Once back in draft, however, it can be deleted — by an Accounting Administrator even where this leaves a gap in the numbering — unless Restrictive Audit Trail is on. The checks run at the annual closing and at each tax return include one on draft entries in the period, which are to be posted or given another accounting date; a failed check can, however, be marked Reviewed or Supervised and passed without being fixed, and each such change is logged in the chatter. The same principle applies to people: a user who leaves is archived, not deleted, so old entries stay attributed to them as posted.

What this requires

• Decide who specifically holds Administrator on Accounting and on Purchase, rather than granting it to every internal user.
• Separate the right to create a vendor or customer — Contact: Creation, and the Administrator levels of Purchase, Sales and Inventory that also carry it — from the right to post an entry.
• Configure 3-way matching and each product's Control Policy before relying on automatic billing, and periodically review vendors set to Auto-post bills: Always.
• Turn on Purchase Order Approval with a Minimum Amount, and build a Studio approval rule for any other document above a set amount, rather than relying on the general posting permission alone.
• Enable Restrictive Audit Trail for the company, and Secure Posted Entries with Hash on the main journals, before go-live, not after.
• Set Lock Everything at each period close and the Lock Tax Return before each tax return is reviewed, and limit Administrator access to Accounting, which can grant exceptions, to those who need it.
• Review each user's Security tab periodically, and archive anyone who leaves rather than deleting them.

The firm's ERP Consulting Department configures access rights, segregation of duties, lock dates and the audit trail in Odoo before go-live, and reviews them periodically afterwards.

Mahmoud Nassef — Chartered Accountant (Egyptian Register), Founder Partner

Member, Egyptian Society of Accountants & Auditors
Member, Egyptian Tax Society
Member, Egyptian Society for Public Finance and Taxation

Partner profile · Book a consultation

Disclaimer: This bulletin is prepared for general information on the legislation in force at the date of its publication. It does not constitute a professional opinion or tax or legal advice on any particular matter, and it should not be relied upon in place of advice based on an examination of the circumstances of each case. Nassef & Partners International accepts no responsibility for any action taken, or refrained from, in reliance on its contents. The positions stated remain subject to subsequent legislation and decisions.