Who Can Change a Price at Two in the Morning

The question that starts most of these conversations is asked in a boardroom and sounds simple. A margin looks wrong on a large order. Somebody pulls the record. The selling price on three lines was changed after the quotation was approved and before the invoice was raised. The change is logged. The log says it happened at 02:14 on a Saturday, and the user was admin.

Nobody in the room knows who admin is. There are four candidates: the finance manager who set it up, the IT contractor who supports the server, the implementation consultant from a partner nobody has worked with in two years, and whoever else has been given the password since. The log is technically complete and evidentially worthless.

That is not a security incident. It is the ordinary consequence of a decision made in week three of the implementation, when a user could not post something, the go-live date was fixed, and the fastest available fix was to widen the role. Nobody wrote it down. It worked. Everyone moved on.

This piece is about that decision and its family: how permissions actually get set in mid-market ERP projects, what segregation of duties means when your finance department is eleven people, and which controls are worth the friction they cause.

The week-three decision

It goes like this in almost every project.

Design is done. Roles were defined in a workshop, on a slide, by people describing an idealised organisation. Then user acceptance testing starts and reality arrives: the storekeeper cannot receive against a purchase order raised by the buyer, because the role was defined too narrowly. The credit controller cannot see the sales order she is being asked to approve. The accountant cannot post a journal in a company he is responsible for.

Each of these is a genuine blocker, raised at four in the afternoon, on a plan with no float. The two available responses are to fix the role properly — which means understanding why the permission is missing, deciding whether it should be there, and testing the change — or to copy a role that works. Copying takes ninety seconds. Fixing takes a day and a conversation.

The role that gets copied is almost always a wide one, because wide roles are the ones that do not produce blockers. By go-live, a meaningful share of your users are carrying permissions that were never designed for them, granted under time pressure, justified by an incident nobody documented.

Nothing then removes them. There is no event in the life of a system that causes anybody to ask whether a permission is still needed. People change jobs and accumulate access. Contractors finish and keep accounts. The system runs for four years and the permission set drifts steadily in one direction, which is outward.

This is a specific instance of a general pattern in the ninety days around a go-live, where the pressure to keep moving converts design decisions into expedients — the subject of why the most dangerous day of your project is not day one. Access is the expedient with the longest tail, because unlike a bad report or an awkward screen, nobody experiences it as a problem until it becomes an expensive one.

What segregation of duties actually means

The principle is older than any software: no single person should be able to both create an obligation and discharge it, or both cause a payment and conceal it. It is not about trust. It is about removing the situation in which one person's mistake or one person's temptation has no second pair of eyes in front of it.

In a mid-market ERP the principle reduces to a handful of combinations that should not sit with the same person. These are the ones that matter, in rough order of how much damage the combination permits.

The combination	Why it matters	What it looks like in practice
Maintaining supplier bank details and releasing payments	The complete fraud, requiring nothing else	One accounts payable clerk who also owns the supplier master
Creating a supplier and approving a purchase order	An invented supplier can be paid for invented work	A procurement officer with master data rights
Receiving goods and approving the invoice	Quantities can be made to match a false invoice	A store in-charge with an AP role "so he can check"
Changing a selling price and raising the invoice	Margin can be moved to a favoured customer	Sales users with price override and invoicing rights
Adjusting stock and counting it	Shrinkage becomes an adjustment nobody investigates	A warehouse supervisor who does both
Setting a credit limit and releasing a blocked order	The credit control is decorative	A sales manager with the override
Maintaining payroll masters and approving the run	A ghost employee, or an unapproved increase	An HR officer who is also the payroll approver
Posting a journal and reconciling the account	Errors and adjustments cover each other	A senior accountant with a wide finance role

Read those as questions to run against your own system rather than as rules to adopt. For each row, ask who in your organisation can do both, and check by looking at the roles rather than by asking. People answer this question with the organisation chart. The system answers it with permissions, and the two are rarely the same.

The master data row is the one to start with

Look again at the first row. In the ERP incidents I have been asked to examine, the transaction is almost never the point of attack. Transactions are visible, numerous, and reconciled. Master data is the point of attack, because a change to a master record is invisible in every report anybody looks at.

A supplier's bank account changed the week before a payment run. A customer's credit limit raised on a Thursday. A price list amended for one item. A cost centre remapped so that a spend lands in a pool nobody reviews. Each of these changes the outcome of hundreds of transactions and appears in none of them.

Which leads to a rule worth adopting whatever else you do: the fields that determine where money goes get change control, not just access control. Supplier bank details, customer credit limits, price lists, tax codes, approval limits themselves. Change control means the change is logged with the identity of a real human being, and — for the bank account field at least — that the change is approved by someone who is not the person making it, before it takes effect.

Most mid-market ERPs will do this with configuration rather than development. Very few are configured to do it, because the requirement never appeared in a workshop.

Approval matrices: a limit is not a control

Every implementation builds an approval matrix. Purchase orders above a value go to a manager; above a higher value, to a director. The matrix is drawn in a workshop, approved, configured, and then quietly defeated by ordinary human behaviour.

Four failure modes account for most of it.

Splitting. If the limit is at a round number, purchases arrive just below it, twice. Any matrix without a mechanism to look at cumulative spend against a supplier or a requisition over a period is measuring the wrong unit.

Delegation without record. The approver goes on leave. Rather than configure a delegation, somebody uses their login. Everything is approved, by the right name, by the wrong person. This is the single most common way an approval matrix becomes fiction, and the fix is trivial: a real delegation function, used, with an expiry.

Approval after the fact. The order was placed on the phone, the goods arrived, and the purchase order is raised afterwards to make the paperwork agree. The approval is genuine and entirely uninformative, because the decision it approves was taken a week earlier by someone else. A matrix that mostly approves things that have already happened is a data entry step.

The approver who cannot evaluate. A director approving forty purchase orders a day approves them all. Their attention is a finite resource and the matrix is spending it on things that do not need it. Fewer, better-targeted approvals are a stronger control than more of them — which is the argument for setting limits by risk rather than by value alone.

The useful test of an approval matrix is not whether it exists. It is: in the last twelve months, how many transactions were rejected at each level? If a level has rejected nothing, it is not a control. It is a delay with a signature on it.

The audit trail question nobody asks until they need it

Every ERP claims an audit trail. The claim is nearly always true and nearly always insufficient, because the question you eventually need to answer is more specific than the log was designed for.

A trail that is worth having answers four questions about any change:

Who — a named individual, not a shared account, not a service account, not admin.

What — the field, the record, the value before and the value after. A log entry saying that a customer record was modified tells you nothing.

When — a timestamp you trust, in a timezone you know.

Why — a reason, captured at the moment of change, for the small set of changes where a reason is worth demanding.

The fourth is the one that is almost never implemented and the one that changes the character of the control. A reason field on a price override or a credit limit increase costs a user four seconds and produces, over a year, a readable narrative of every exception the business made. It also has an interesting effect on behaviour: people make fewer indefensible changes when they have to type a defence.

There is a second requirement that only surfaces under examination: retention. Your audit trail is only useful for the period it is kept, and some systems trim logs for performance. Find out what your retention is before an auditor asks, because the answer sometimes turns out to be ninety days. That question sits close to the record-retention demands that an FTA audit makes of your system rather than of your team, and both are answered by the same piece of configuration work.

What to do when you cannot segregate

Here is the honest problem with everything above. Segregation of duties assumes you have enough people to separate. A UAE trading company with six people in finance cannot allocate eight incompatible functions to eight individuals, and telling them to is advice they will correctly ignore.

The answer is not to give up. It is to accept the combination and put a detective control behind it, deliberately and in writing. The pattern is always the same shape: if a person can do two things that should not be combined, someone else has to look at the result on a defined cadence.

Some that work in small teams, at low cost:

The bank detail change report. Every change to a supplier bank account in the period, reviewed by someone outside accounts payable, before the payment run. Ten minutes a month.

The price override report. Every sale below the price list, by user, by customer, with the reason field. Reviewed by whoever owns margin.

The manual journal review. Every journal not generated by a transaction, listed with its narration, reviewed by the finance director or the audit committee. The list is short in a healthy month and the exceptions are visible.

The new supplier list. Suppliers created in the period, with their first transaction. Cross-check against the employee address and bank records at least annually.

Access recertification. Twice a year, every manager receives the list of what their people can do and confirms it or cuts it. This is the one that most directly reverses the drift described at the start, and it is the one most often proposed and least often actually run.

None of these require software you do not have. They require someone to decide they are somebody's job on a specific date, which is a governance act rather than a technical one, and the reason governance belongs in the plan before the platform does.

The accounts that should not exist

Three specific things to go and check today, before any broader review.

Shared logins. Any account used by more than one person destroys the "who" in every log entry it appears in. They exist because a licence was expensive, or because a shift pattern seemed to need one, or because a store terminal is used by whoever is on duty. Each has a real answer — named accounts with a role, or a device-level identity with a user selection — and each costs less than the incident.

Dormant accounts with live access. The consultant from the implementation. The employee who left in March. The test user created during UAT with everything enabled. Run a report of accounts with no login in ninety days and see what comes back. In most systems the list is longer than anyone expects and includes at least one account with full rights.

Superuser access held permanently. Somebody has to be able to fix things, and in a small company that person is usually the finance manager or an external support partner. Holding that access permanently is different from being able to obtain it. The better arrangement is a break-glass account: credentials held sealed, issued when needed with a record of who asked and why, changed afterwards. It sounds bureaucratic for a company of ninety people. It takes about an hour to set up and it converts an open door into a recorded event.

What week three should look like instead

None of this argues for a heavier project. It argues for one decision to be made differently under pressure.

When a blocker appears in testing and the fastest fix is to widen a role, the rule is: widen it, and write it down. One line in a log — who asked, what was granted, why, and a date to revisit. That log takes a minute per entry and by go-live it is a list of every compromise the project made, in one place, owned by someone.

Then, four to six weeks after go-live, when the system is stable and the pressure has dropped, that list is worked through. Some entries turn out to be correct and become permanent. Some turn out to have been a workaround for a configuration error that can now be fixed properly. Some are simply removed, and nobody notices.

The value is not in the discipline of the logging. It is that the list exists at all. The alternative — the one that happens by default — is that the compromises are invisible, distributed across four hundred permission entries, and discovered years later by someone querying a log that says admin changed a price at two in the morning.

If you want a structured view of where your current permissions and controls sit before an auditor or an incident tells you, the go-live risk assessment covers access design alongside the other things that decide whether a system survives its first year — and the same questions are worth asking of a system that went live long ago.