SAP Business One audit and project takeover in the UK

A SAP Business One audit is an independent review of an installation that already exists, whether it went live badly or never quite finished. Its purpose is simple: establish what works, what does not, and what it would take to fix it, before you commit more budget. For many UK small and mid-sized companies it is also the first step towards a SAP Business One project takeover, where the work passes to a different integrator without starting from zero.

SAP says the product serves more than 83,000 customers and 1.2 million users, and that it is sold through 850 partners. A wide partner base means quality varies. Problems with a SAP Business One project are rarely about the software itself; they are usually about scope, configuration choices, bespoke code and handover discipline.

Signs that a SAP Business One audit is overdue

You do not need a crisis to justify a review. These symptoms, taken together, usually mean the installation needs an objective look:

• The finance team keeps shadow spreadsheets. If your accountant reconciles stock, VAT or intercompany balances outside the system every month, the configuration probably does not match how you trade.
• Fixes do not hold. An issue is closed, then reappears after the next change. That points to design problems rather than isolated faults.
• Nobody can explain the customisations. Add-ons and queries exist, but no one can say what they do, who wrote them or whether they survive an upgrade.
• Go-live keeps slipping, or the system went live with a long list of "phase two" items that never started.
• Users work around the system. Sales staff quote from email, the warehouse prints lists and re-keys them, and payroll data is retyped.
• Reports disagree. The stock valuation differs from the ledger, or two reports give different sales totals for the same period.
• Support is slow or evasive, and answers depend on one person at the integrator.
• The version is old. More on this below, because it changes the risk profile considerably.

A comparable list appears in our guide to common ERP project mistakes, which is worth reading alongside this page if the project is still under way.

What a proper audit examines

A credible audit is scoped in advance, mostly read-only and produces a written report. It should cover the following areas.

Configuration and processes

The auditor compares how the system is set up with how the business actually works. That means company settings, posting periods, document numbering, approval procedures, pricing logic, tax codes and warehouse structure. The question is never "is this setting valid?" but "does this match the process the company needs?".

Finance is the first place to look. Check the chart of accounts, the account determination rules and the period-end routine, then compare them with the obligations described in our guide to Making Tax Digital and ERP software. A system that cannot produce a clean VAT return without manual correction has a configuration problem, not a reporting one.

Data quality

Poor migration is the most common root cause of lasting distrust. The review samples customers, suppliers, items, price lists, opening balances and open documents. It looks for duplicates, inconsistent units of measure, orphaned records and balances that do not reconcile. If migration was the weak point, the SAP Business One migration page explains how a clean reload differs from patching bad data.

Custom development and add-ons

Bespoke work deserves the most scrutiny. The auditor inventories user-defined fields, tables and objects, queries, formatted searches, stored procedures, add-ons and scripts, and notes for each: purpose, author, documentation, dependency on a specific version. Undocumented code owned by a single developer is a continuity risk. Our page on SAP Business One customisation sets out what good practice looks like, so you have a benchmark for the findings.

Integrations

Connections to e-commerce platforms, banks, payroll, carriers or a CRM often fail quietly. The review checks how each interface runs, what it does on error, who is alerted and whether data can be replayed. For a wider view, see SAP Business One integrations.

Performance and infrastructure

Slow screens, long-running reports and blocked sessions have causes that can be measured: database sizing, indexes, scheduled jobs, network and server resources. The auditor also checks backup routines and, importantly, whether a restore has ever been tested. If the system is hosted, the review should confirm who is responsible for what.

Security and licensing

Access is reviewed role by role: who can post, who can change master data, who can see payroll. The auditor looks for shared logins, dormant accounts and users with more rights than their job needs.

Licensing deserves attention too. SAP's licence guide allows the "manager" user to log in from two separate Windows sessions without locking the first, so that scheduled tasks such as reporting or imports can run, or so that a consultant can connect without a licence. It does not permit double productive use. A review should confirm that nobody is relying on that allowance for daily work.

For on-premise installations, the licence guide also describes a support user created at installation so that partner staff can log in without consuming a licence. It is locked by default and logged, and login is refused if the Remote Support Platform has not sent data in the last seven days. The auditor should check that this account is controlled, that the platform is working and that the partner's access is something you have chosen, not something you have forgotten.

Version and support position

Finally, the auditor establishes where you stand on the maintenance timeline. According to SAP, version 10.0 is in standard maintenance until 31 December 2028, subject to change, while versions 8.8, 8.81, 8.82, 9.0, 9.1, 9.2 and 9.3 have ended standard maintenance. SAP also states that extended maintenance is not offered, and that it provides no corrections or security patches for older feature packages, support packages, patches or hotfixes.

This matters for upgrade planning too. SAP supports direct upgrades only between consecutive versions, such as 9.3 to 10.0; anything else needs several steps. If you are behind, the upgrade path is a cost and timing question your report must answer. See SAP Business One versions and editions for the background.

What the audit report should contain

Ask for a document you can act on, not a slide deck of impressions. A useful report has:

Insist that the report distinguishes fact from opinion. It should say what was tested and what was not.

Changing integrator without starting again

Many companies delay a change of partner because they assume everything must be rebuilt. In practice a change of SAP Business One integrator is mainly a handover exercise. The system, the data and the licences are yours.

Before you give notice

Check your contract: notice periods, ownership of custom code, hosting arrangements and any retained support obligations. Take advice if there is a dispute. Keep the tone professional; you will need cooperation for the handover.

Documents and access to recover

Ask the outgoing integrator, in writing, for the following:

• the signed scope, functional specification and change requests;
• configuration notes, process maps and any test scripts and sign-off records;
• the full list of customisations with source code, add-on installers and licence details;
• integration descriptions, credentials ownership and schedules;
• database and server details, backup schedule and the most recent verified backup;
• administrator-level access, with a named superuser account held by your company;
• the open issues log and any outstanding invoices or milestones;
• training material and user guides produced for your staff.

Do not rely on goodwill alone. If the system sits in an environment the integrator controls, make sure you can reach the data and the licence keys independently. The SAP Business One hosting and cloud page explains who holds what in hosted arrangements. SAP's own terms also require a partner to hold a "Run Authorization" to resell its hosted cloud subscription, so ask any hosting partner to confirm their standing.

The takeover sequence

A sensible takeover keeps the business running while risk is reduced:

1. Secure. Take a verified backup, confirm administrator access and freeze non-essential changes.
2. Assess. The incoming partner runs a read-only audit, as described above.
3. Stabilise. Fix what stops people working: posting errors, blocked documents, failing interfaces.
4. Decide. Agree with the incoming partner which parts to keep, repair or rebuild, and what each costs.
5. Rebuild selectively. Rework weak areas, retrain users and retest with real transactions.
6. Hand over properly. Documentation, a support route and a plan for the next upgrade.

If the audit concludes that the foundations are unsound, a fresh start may be cheaper than repair. That is a legitimate outcome, but it should come from evidence, not frustration. The SAP Business One implementation page describes what a well-run start looks like.

Building a recovery plan that sticks

A recovery plan is more than a task list. It needs owners and a way to measure whether the system is getting better.

Agree the target first. Decide what "working" means: a closed month-end without workarounds, a VAT return produced from the system, stock that matches the count, orders flowing without re-keying. Write these as acceptance tests.

Put a named person on your side in charge. Troubled projects often lack an internal owner with authority. Whoever leads the recovery must be able to make process decisions and release staff for testing.

Fix data before features. Adding functionality on top of unreliable master data compounds the problem.

Retrain deliberately. Users who learned workarounds will keep them unless the correct process is shown to be easier. Refresh sessions are often more valuable than new modules; see SAP Business One training.

Set up support before you need it. Agree response routes, escalation and who owns issues. SAP's maintenance page mentions round-the-clock support from SAP for system standstill incidents, but day-to-day help comes from your partner, so the arrangement should be explicit. Our page on SAP Business One support and maintenance explains what to specify.

Plan the next upgrade now. Since SAP delivers innovation through cumulative feature packages from version 10.0 onwards, with stable interfaces between the major version and those packages, a well-governed system can stay current in smaller steps. A neglected one faces a larger jump later.

Choosing the partner who takes over

Selecting a rescue partner differs from selecting a first implementer. You are buying judgement as much as capacity. Look for a team that:

• offers a defined, read-only review before quoting for remediation;
• is comfortable inheriting someone else's custom code, and explains how it will be maintained;
• speaks plainly about causes, including those on your side, such as unclear requirements or limited user availability;
• can describe how it works with UK finance teams, including VAT, Making Tax Digital and payroll reporting.

Our page on choosing a SAP Business One partner gives a fuller checklist. If you would like candidates matched to your situation, how the service works explains how we introduce a SAP Business One integrator without charging you for the introduction. We do not carry out audits or projects ourselves, and we are not affiliated with SAP.

Before you commission an audit

A little preparation makes the review faster and more useful. Gather the original requirements, any contract or statement of work, a list of known problems with examples, and a list of users and their roles. Name an internal contact for each department. Tell the auditor what you fear, as well as what you know: if you suspect a particular add-on or interface, they should look there first.

An audit is not an accusation. It is a way to replace arguments with evidence, so that the next decision, whether to repair, rebuild or change partner, is made on facts.

Software names mentioned are trademarks of their respective publishers and are referred to for information only. This site is independent and is not affiliated with any software publisher.