A person appears to have entered the wrong number.
During South Africa’s May 2026 fuel-price calculation, an additional diesel levy reduction of 93.00 cents per litre was captured as 0.93 cents per litre.
That mistake contributed to an announced diesel wholesale-price increase of R6.19 per litre instead of the corrected R5.27 per litre.
The Department of Mineral and Petroleum Resources corrected the figure before the new prices took effect on 6 May 2026.
It would be easy to treat this as an embarrassing decimal error and move on.
That would miss the more useful lesson.
People make mistakes. They mistype figures, select the wrong field, misunderstand units, use an outdated source or overlook an inconsistency. Serious processes need to be designed around that reality.
A good system does not remove people from the work. It helps them enter information correctly, makes unusual values visible and gives reviewers a clear route for checking the result.
The mistake was human.
The process failure was allowing that mistake to move through calculation, review, approval and publication without being stopped earlier.
This article is part of the Process Failure Case Studies series, which examines what happens when information, evidence, review and reporting processes break down.
Who this guide is for
This case is relevant to:
- public-sector and policy teams;
- finance and pricing teams;
- research and evaluation teams;
- monitoring and reporting teams;
- organisations publishing figures for public use;
- analysts working with controlled calculations;
- and managers responsible for review and sign-off.
Most organisations will never calculate a national fuel price.
They may still rely on spreadsheets, databases, formulas, reports and dashboards where one incorrect value can affect a serious output.
What happened with the May 2026 diesel price?
On 4 May 2026, the South African government published its fuel-price adjustment announcement for prices taking effect on 6 May.
The announcement explained that government had extended a temporary reduction in the general fuel levy.
The published relief was:
- 300.0 cents per litre for petrol; and
- 393.0 cents per litre for diesel.
The same announcement stated that both grades of diesel would increase by R6.19 per litre.
On 5 May, the Department of Mineral and Petroleum Resources issued an official erratum.
The department explained that the additional 93.00 cents per litre reduction for diesel had been incorrectly captured as 0.93 cents per litre during the calculation.
The corrected diesel increase was R5.27 per litre.
In simple terms:
| Item | Incorrect calculation | Correct calculation |
|---|---|---|
| Additional diesel levy relief | 0.93 c/l | 93.00 c/l |
| Announced diesel increase | R6.19/l | R5.27/l |
| Difference | Approximately 92 c/l |
The correction reduced the announced diesel increase by almost R1 per litre.
The revised figure was issued before the adjustment came into effect. The incorrect R6.19 increase therefore did not become the official May diesel adjustment.
That matters. The correction prevented a larger operational problem.
It does not answer how the original error passed through the process.
“Human error” is the start of the diagnosis
The department said the value was “erroneously captured”.
The available public statements do not identify:
- the person who entered the figure;
- the tool used;
- whether the information was typed, copied or imported;
- the formula or calculation structure;
- the internal review process;
- or the person who approved the first announcement.
It would therefore be speculative to blame a spreadsheet, a database, a particular software platform or a specific official.
What can be said is that a wrong value entered the calculation.
Someone should have entered 93.00 and entered 0.93 instead.
That is a human mistake.
But serious calculations should not depend on one person never making a mistake.
Someone else should have checked the entry. The calculation should have been compared with the approved levy decision. The final result should have been tested against the expected movement. The public statement should have been checked for internal consistency.
Calling something “human error” can sometimes become a way of ending the investigation too early.
A better set of questions is:
- Why was the mistake possible?
- Why was it not detected at entry?
- Why did the calculation not flag the unusual value?
- Why did review not catch the difference?
- Why did approval not reconcile the result with the source decision?
- What will change before the next calculation?
That is where process design begins.
The original announcement contained its own warning
One of the clearest parts of this case is that the original announcement contained both:
- the correct diesel levy relief of 393.0 cents per litre; and
- the incorrect diesel price increase of R6.19 per litre.
The policy input and the calculated output appeared in the same public statement.
According to the later correction, the calculation had failed to apply 92.07 cents per litre of the approved additional relief.
A proper reconciliation should have raised a question:
> The announcement says diesel is receiving R3.93 per litre in temporary levy relief. Does the final price movement reflect that relief?
A reviewer may not need to rebuild every part of the fuel-price calculation from the beginning.
They do need to check whether the important inputs and outputs agree.
This is the difference between reading a document and reviewing a process.
A document can look complete, use the correct terminology and contain neatly formatted figures while still being wrong.
The wrong lesson is to blame the spreadsheet
The available public record does not establish that a spreadsheet caused the error.
Even if a spreadsheet was involved, the tool would not be the complete explanation.
A spreadsheet can contain:
- protected fields;
- lookup tables;
- source links;
- range checks;
- variance warnings;
- locked formulas;
- review fields;
- version controls;
- and recorded approvals.
A custom system can also be poorly designed.
It can accept unclear values, hide units, overwrite records and publish outputs without proper review.
The more useful distinction is not:
spreadsheet versus software
It is:
controlled process versus uncontrolled process
A simple tool with clear fields, validation and human review can be safer than expensive software with weak rules and unclear ownership.
The system matters, but the people using, checking and approving it still carry responsibility.
The wrong lesson is also to automate everything
The other easy response is to say that the calculation should have been fully automated.
Automation may have helped.
For example, the approved levy value could have been imported directly into the calculation instead of being entered manually. The system could also have compared the entered figure with the approved source and flagged the mismatch.
But automation does not remove the need for human judgement.
Automated systems can:
- import the wrong source;
- apply an outdated rule;
- use an incorrect mapping;
- preserve a faulty formula;
- or reproduce a mistake across every output.
The safer approach is not to remove people.
It is to give people better controls.
The system should handle repeatable checks. People should investigate exceptions, interpret the result and remain responsible for sign-off.
Where the process should have caught the error
Based on the public information, there were several possible control points between the original entry and the published announcement.
The department has not published its complete internal workflow, so these should be treated as questions for process review rather than claims about controls that definitely did or did not exist.
1. The input stage
The field used for the levy reduction should have made the unit clear.
For example:
Additional diesel levy reduction in cents per litre
A field labelled only “additional reduction” creates room for uncertainty.
The input structure could also have required:
- the approved value;
- the previous value;
- the new value;
- the unit;
- the effective date;
- a source reference;
- the person entering the value;
- and the person checking it.
The system could then compare the captured value with the approved source.
This is part of designing better Data Collection & Intake Systems.
The objective is not only to collect a number. It is to collect enough context for that number to be checked and used correctly.
2. The validation stage
A difference between 0.93 and 93.00 should have been treated as an exception.
The system could have checked whether:
- the value fell outside an expected range;
- the decimal precision was unusual;
- the entered amount differed from the approved amount;
- the change was unusually large or small;
- or the value conflicted with another field.
A warning could have said:
> Additional diesel levy relief entered as 0.93 c/l. Approved source records 93.00 c/l. Confirm before continuing.
The system would not need to decide which figure was correct.
It would stop the process and require a person to check.
3. The calculation stage
The calculation should have shown how each input affected the final result.
A useful reconciliation view might contain:
| Check | Source value | Value used | Difference | Status |
|---|---|---|---|---|
| Additional diesel levy relief | 93.00 c/l | 0.93 c/l | 92.07 c/l | Review required |
This is a basic source-to-calculation check.
The important point is not that every organisation needs this exact table.
The important point is that a reviewer should be able to see:
- where the input came from;
- what value was used;
- whether the two agree;
- and how the value affected the output.
That is the purpose of a traceable evidence workflow.
4. The independent review stage
A second person reading the completed announcement is not necessarily an independent review.
People often read what they expect to see.
A reviewer may check grammar, dates and formatting without testing the calculation. They may assume the numbers have already been approved elsewhere.
A proper review should state what must be checked.
For a high-consequence calculation, the checklist could include:
- approved source compared with captured input;
- units checked;
- decimal places checked;
- formulas checked;
- current result compared with the previous version;
- material changes explained;
- calculation output compared with the public statement;
- and the final version independently approved.
The reviewer should record their name, date and decision.
A generic “reviewed” status is not enough if nobody knows what was reviewed.
5. The publication stage
The final public statement should have been tested for consistency.
The statement said the temporary diesel levy relief was 393.0 cents per litre.
It also published a price result that did not reflect 92.07 cents of that relief.
A final publication check should have compared:
- the approved policy decision;
- the calculation input;
- the calculation output;
- the explanatory text;
- and the final price table.
This is where Data Use, Reporting & Communication Systems become relevant.
An organisation needs to know:
- which version is final;
- whether every published figure has been checked;
- whether the narrative agrees with the table;
- who approved the output;
- and whether the publication can be traced back to the working calculation.
The output layer needs its own controls.
6. The correction stage
The department identified the issue, issued an erratum and corrected the result before the new price took effect.
That part of the process worked.
The correction reduced the announced increase by about 92 cents per litre and limited the effect on diesel users.
Farmer’s Weekly reported that diesel remains an important input for mechanisation, irrigation, harvesting, transport and backup power across agriculture.
A wrong diesel adjustment would not have affected only private motorists.
It could have affected farms, transport operators, delivery costs, generators and other diesel-dependent operations.
A correction workflow is therefore necessary.
It should include:
- one owner for the correction;
- a record of the original and corrected figures;
- timestamps;
- approval of the correction;
- withdrawal or replacement of the incorrect version;
- communication to affected users;
- and a review of why the earlier controls failed.
The department’s correction prevented the error from becoming the effective May price.
The stronger outcome would have been catching it before the first announcement.
What a better process could look like
A safer workflow would connect the approved decision, working calculation, review and public output.
| Stage | Human responsibility | System support |
|---|---|---|
| Approved decision | Confirm the authorised levy change | Store the source, date, version and approval |
| Data capture | Enter or confirm the value | Require units, apply range checks and compare with the source |
| Calculation | Interpret whether the result makes sense | Apply formulas, display variances and flag exceptions |
| Review | Independently check the input and output | Provide a checklist, comparison view and review status |
| Approval | Accept responsibility for publication | Lock the approved version and record sign-off |
| Publication | Confirm the public statement matches the approved calculation | Compare narrative, tables and final figures |
| Correction | Investigate and communicate the change | Keep an audit log and link the erratum to the original |
This is not a purely technical design.
Every stage still has a person responsible for completing the work.
The system supports that responsibility by making the relevant information visible.
Systems should help people do their jobs properly
A badly designed process usually creates one of two problems.
The first is overreliance on people remembering every check.
The second is overreliance on software being correct because it is software.
Neither is safe.
People need:
- clear fields;
- visible units;
- approved source material;
- defined responsibilities;
- useful warnings;
- review checklists;
- enough time to investigate;
- and authority to stop publication when something does not reconcile.
A warning that everyone routinely ignores is not a control.
A checklist completed without checking the underlying source is not review.
A senior sign-off based only on a polished final document is not assurance.
The process has to make the right work possible and expected.
Why this matters beyond fuel pricing
The same pattern appears in smaller organisations every day.
A figure is entered incorrectly.
It moves into a formula, table, dashboard, report or client document.
Nobody notices because each person assumes somebody else checked it.
Examples include:
- a donor report using the wrong beneficiary total;
- an evaluation applying the wrong denominator;
- a monitoring dashboard mixing monthly and cumulative figures;
- a budget using rand in one table and thousands of rand in another;
- a public-submission database double-counting duplicate records;
- an AI assistant retrieving an outdated policy document;
- a board report using figures from the wrong reporting period;
- or a public document publishing information that should have been removed.
The initial error may be small.
The effect grows as it moves downstream.
An incorrect input becomes:
- a calculation
- a table
- a report
- an approved output
- a public or operational decision
That is why the route matters.
Human review must be designed into the workflow
“Human in the loop” is often used as a vague reassurance.
It means little unless the human has:
- a defined review task;
- access to the source;
- enough context to understand the figure;
- a clear exception to investigate;
- a place to record the decision;
- and responsibility for the result.
A person clicking “approve” is not automatically meaningful human review.
The review has to be specific.
For example:
- Did the entered value match the approved decision?
- Was the unit correct?
- Did the calculation use the right version?
- Did the output move by the expected amount?
- Were all material variances explained?
- Does the public statement agree with the final calculation?
Human review works when the process tells people what they need to review and gives them the information needed to do it.
The same principle applies to evidence and reporting
The diesel-price error concerned a controlled calculation.
The same source-to-output principle applies to research, policy and reporting.
A finding should link back to evidence.
A recommendation should link back to a finding.
A public claim should link back to a source.
A figure in a report should link back to the working data.
A corrected output should preserve a record of what changed.
This is also the issue examined in South Africa’s AI policy evidence-trail failure.
In that case, fake or unverifiable references appear to have moved into a public policy document without being stopped by the review process.
In the diesel case, a wrong value moved into a public price announcement.
The details differ.
The underlying question is similar:
> Could the final output be checked against the source before it was published?
A practical example of a traceable workflow
The Local Government White Paper evidence-workflow case study shows how this principle can work in an evidence-heavy policy process.
Public submissions, coded claims, source locators, themes, drafting support and later review comments needed to remain connected.
The workflow did not depend on people remembering where every point came from.
It gave the team a structured route for checking:
- the original source;
- the extracted claim;
- the theme;
- the synthesis;
- the drafting use;
- and the review status.
The subject was different from fuel pricing, but the working principle was the same.
The source and the output should not become separated.
Where my work fits
I do not calculate fuel prices or audit the department’s internal pricing process.
My work fits around the information route that organisations use to collect, check, analyse and publish important material.
Data Collection & Intake Systems
Data Collection & Intake Systems can help teams define:
- controlled fields;
- clear units;
- validation rules;
- source references;
- required metadata;
- exception warnings;
- and review responsibilities.
The aim is to collect information in a form that is ready for later checking and use.
Traceable Evidence Workflow Support
Traceable Evidence Workflow Support can help connect:
- original sources;
- captured values;
- calculations;
- evidence records;
- changes;
- reviewer notes;
- approval decisions;
- and final outputs.
The Source Traceability Risk Checker can help teams identify where source links, review records and approval routes are weakest.
Data Use, Reporting & Communication Systems
Data Use, Reporting & Communication Systems can support:
- report and dashboard logic;
- controlled versions;
- consistency checks;
- review statuses;
- publication workflows;
- sign-off;
- and correction records.
The Reporting Bottleneck Cost Calculator can also help estimate the time and cost being lost through manual checking, repeated corrections and late-stage review.
The objective is not to automate responsibility away.
It is to build a process where people can see what needs checking, complete the review properly and remain accountable for the result.
What organisations should learn from this case
The lesson is not that people cannot be trusted with important calculations.
The lesson is that important calculations should not rely on perfect people.
A safer process assumes that mistakes are possible.
It then creates multiple opportunities to detect them:
- The input is clearly defined.
- The value is linked to an approved source.
- The system checks the format and range.
- The calculation shows material variances.
- Another person reviews the source and result.
- The final document is reconciled before publication.
- The approval is recorded.
- Any correction feeds back into the next version of the process.
That is what good process control looks like.
Not replacing people.
Helping people catch errors before those errors become official outputs.
FAQ
What was South Africa’s May 2026 diesel-price error?
The Department of Mineral and Petroleum Resources said an additional diesel levy reduction of 93.00 cents per litre was captured as 0.93 cents per litre during the May fuel-price calculation.
This contributed to an announced diesel wholesale-price increase of R6.19 per litre instead of R5.27 per litre.
Was the incorrect diesel price implemented?
The department issued the correction before the new fuel-price adjustment took effect on 6 May 2026.
The corrected diesel increase was R5.27 per litre.
Was this a spreadsheet error?
The public erratum does not identify the tool used.
It confirms that the value was incorrectly captured during the calculation. Without further evidence, it would be inaccurate to say that a spreadsheet, database or particular software system caused the mistake.
Was the problem caused by a person or by the system?
The original incorrect capture appears to have been a human mistake.
The wider process problem was that the mistake was not detected before publication.
A complete review should therefore examine both individual responsibility and the controls surrounding the work.
Could automation have prevented the error?
Automation could have reduced the risk.
For example, the system could have imported the approved value directly, compared it with the captured amount or flagged a difference outside the expected range.
Automation could not remove the need for a person to review the source, investigate the warning and approve the final output.
What should an independent reviewer check?
The reviewer should check more than whether the document looks complete.
They should compare:
- the approved source;
- the value used;
- the unit;
- the formula;
- the difference from previous versions;
- the expected result;
- the calculated result;
- and the public statement.
The check should be recorded.
Why is source traceability relevant to a calculation?
Source traceability allows a reviewer to see where an input came from, which version was used, who entered it and how it affected the final output.
Without that route, the reviewer may see only the completed number and have no practical way to verify it.
A useful next step
A process should not depend on people never making mistakes.
It should help people find mistakes while there is still time to correct them.
If your team relies on calculations, evidence tables, reports, dashboards or public outputs that are difficult to check, start by mapping the route from the original source to the final result.
Where did the information come from?
Who entered it?
What rules were applied?
What should have been flagged?
Who reviewed it?
Who approved publication?
Can the final output still be traced back to the source?
If that route is unclear, you can send me a short project brief.
Sources
Data Collection & Intake Systems
Collect useful, traceable data from the start through forms, fieldwork tools, public submission portals, partner reporting systems, calculators, and intake workflows.