How to Tell Whether a SAP Business One Agency Is Over-Customising Your ERP
Picture a mid-sized distributor, two years after go-live. The ERP was supposed to calm things down. Instead, every month-end close leans on a custom export that nobody fully understands, the last upgrade was postponed twice, and a small change to a purchase approval rule has just come back with a quotation attached. The finance director asks a fair question: why does a system bought to simplify the business keep asking for more money?
That is an illustrative scenario, but most SAP Business One users will recognise some of it. Customisation is not the villain here. Plenty of businesses genuinely need it. The trouble starts when a SAP Business One agency builds something that standard features, a configuration change or an established add-on could already have handled.
How can you tell if a SAP Business One agency is over-customising your ERP?
Look for custom features that duplicate standard functionality, development quotes for every small change, upgrades that keep getting harder, costs nobody can explain, thin documentation, and a business that relies on one developer or one agency to keep core processes running.What Does Over-Customisation Mean in SAP Business One?
So, what does "over-customisation" really mean in SAP Business One? It's about creating custom features your company doesn't actually need, or stuff the software could handle right out of the box. The question isn't, "How much did we build?" It's really, "Does each thing we've added actually make sense?" There is a real difference between adapting the ERP to a genuine requirement and bending it to copy the old way of working. Many projects drift towards the second. A team arrives with ten years of spreadsheets and habits, the agency is asked to reproduce every step, and nobody stops to ask whether the step should exist at all. Each reproduction adds code that has to be tested, documented, supported and carried through every upgrade. Add enough of it and the implementation gets heavier, support slows down, and a version change becomes a project of its own.Is SAP Business One customisation always a bad idea?
No. Specialised industry workflows, regulatory requirements and processes that standard functionality cannot reasonably support are all good reasons to build. A German business may need particular archiving or export behaviour to satisfy GoBD and DATEV expectations, and an Indian company may have to deal with GST e-invoicing. Even then, the first move is to check what localisation content and certified solutions already exist. Custom work should be what is left when those options run out.Can SAP Business One work without customisation?
For many small and mid-sized businesses, largely yes. The product ships with accounting, purchasing, inventory, sales and reporting, and configuration closes much of the remaining gap. Whether that is enough for you is something to test, not assume.SAP Business One Configuration vs Add-Ons vs Custom Development: What Is the Difference?
Before anyone approves a build, there are four routes worth weighing, and they are not interchangeable.| Approach | What it means | When to consider it | Example |
| Standard functionality | Features that already exist in SAP Business One | The requirement is already supported | A normal buy-and-stock flow using standard purchasing and inventory documents |
| Configuration | Adjusting settings, workflows and permissions | Existing features need to follow your business rules | An approval template that sends large purchase orders to a second approver |
| Third-party add-on | Extending the ERP through a supported solution | A specialist capability is required | A certified e-commerce connector that syncs web orders and stock |
| Custom development | |||
| Building functionality for one company | Alternatives cannot adequately meet a justified requirement | A bespoke pricing engine for an unusual contract structure |
Which SAP Business One features should you check before requesting development?
Sit down with your agency and walk through what is already there: accounting, purchasing, inventory, sales, customer management, reporting, approvals and analytics. Ask to see it working with your own data, not on a slide. Exact capabilities depend on your version, your configuration and your requirements, so a demonstration in your environment is worth more than any general claim, including the ones in this article. SAP’s own material, such as its guidance on approval processes in SAP Business One, is a useful way to see what standard already covers.What Are the 7 Warning Signs Your SAP Business One Agency Is Over-Customising Your ERP?
These are the patterns that come up most often. Each one comes with an example, what it costs you, and what to do about it.1. Your agency recommends custom development before exploring standard SAP B1 features
Watch the order of events. If the first proposal is a build and nobody has shown you the standard feature set, something is the wrong way round. Take a purchasing approval app. Standard SAP Business One lets you set up approval procedures for sales, purchasing and inventory documents, with stages, conditions and substitute approvers for when someone is away. A bespoke app can still be justified when the rule depends on data held outside the ERP, but often it is not. The cost is paying to build and maintain something you already owned. Ask for a fit-to-standard session before any estimate is signed.2. Simple process changes require additional development
A new approval threshold. An extra column on a report. A different route for credit holds. If each of these arrives as a development quotation, the system has probably been built too rigidly. Some changes do need code. Many are settings, permissions or query adjustments that a consultant can handle in an afternoon. The cost shows up as slow change: your business moves and your ERP waits for a ticket. Ask your agency to label every request as configuration or development, and to explain the label.3. Your SAP Business One upgrades are becoming increasingly difficult
Custom components and integrations add compatibility and regression testing to every version change. If upgrades keep slipping, or each release is followed by a week of broken screens, the extension layer may be carrying more weight than it should. Put one question to your agency: has every critical extension been tested against the target SAP Business One version, and can they show you the results? SAP’s help documentation includes compatibility guidance, and your agency should be working from it.4. Your ERP contains multiple add-ons with overlapping functions
Two reporting tools. A pair of document-processing utilities from different vendors. A dashboard add-on that repeats what a standard report already shows. Each brings licence fees, its own screens, its own update cycle and its own vendor to chase when something breaks, and users end up unsure which tool is meant for which job. List every add-on with its purpose, owner and renewal date, then ask which ones overlap.5. Your business depends on one developer to maintain critical processes
If one person holds the knowledge of how your pricing logic or month-end export works, you have a continuity risk rather than a feature. Look for missing handover notes, unclear source-code ownership and an agency that goes vague when you ask who else could support the work. When that person is away, moves on, or the relationship ends, the process is held hostage. Ask for documentation and written confirmation of who owns the code, and have a second engineer walk through each critical component.6. Your agency cannot clearly explain the cost or business value of each customisation
Ask what a particular customisation cost to build, what it costs each year to keep, and what it saves. If the answer is a shrug, the work was never justified in business terms. Every build should have a written expectation attached: hours saved, errors avoided, risk reduced. Without it, nobody can say later whether the thing was worth keeping.7. Employees are using workarounds despite extensive ERP customisation
Walk through the finance office. If people still keep a spreadsheet beside the ERP, retype data between screens or reconcile by hand every Friday, the development has not solved the problem it was commissioned for. Often the underlying process was never fixed, only wrapped in code. Before approving any further build, watch real users work for an hour. What are the signs of SAP Business One over-customisation? The table below puts all seven side by side.| Warning sign | Likely root cause | Business impact | Corrective action |
| Build before standard is explored | No fit-to-standard step in the project | Paying for features you already own | Require a standard-feature demonstration before any estimate |
| Every small change needs development | Rigid design, little configuration | Slow change and rising quotes | Classify each request as configuration or development |
| Upgrades keep getting harder | Untested extensions and integrations | Delayed upgrades, post-release fixes | Request a compatibility list and test results per extension |
| Overlapping add-ons | Tools added one project at a time | Duplicate licences, confused users | Inventory add-ons and retire the duplicates |
| One developer holds the knowledge | Weak handover and documentation | Continuity and ownership risk | Obtain documentation and written code-ownership terms |
| No cost or value case | Builds approved without business justification | Unknown return on spend | Record expected savings or risk reduction for each item |
| Workarounds persist | Process problem never fixed | Manual effort, errors, double entry | Observe users, then redesign the process before more code |
How Much Can Unnecessary SAP Business One Customisation Cost Your Business?
What are the hidden costs beyond initial development?
The quote for the build is the visible part. Underneath sit documentation, testing, support calls, compatibility checks at every upgrade, staff training and the upkeep of any integration that touches the custom piece. These rarely appear in the original proposal, and they repeat.How does customisation affect the total cost of ownership of SAP Business One?
A simple way to think about it: Total customisation cost = initial development + ongoing maintenance + upgrade testing + integration changes + training + remediation Here is a hypothetical year-one comparison in effort days. The numbers are invented only to show the arithmetic. A custom approval app might take 20 days to build, 3 for maintenance, 4 for upgrade testing, 2 for integration changes, 1 for training and 3 for remediation, which comes to 33 days. A configured approval procedure for the same rule might take 3 days in total. These are not benchmarks, and your figures will differ. The point is that the custom route keeps generating cost every year it stays in place.How Can Over-Customisation Affect SAP Business One Performance, Security and Upgrades?
Can custom development slow down SAP Business One?
It can. Inefficient queries, needless processing, heavy integration traffic and poorly designed extensions all take their toll. But slowness has many causes, including hardware, database configuration and data volume, so any performance complaint needs diagnosis before anyone blames the customisations.Can customisations create security or data integrity risks?
Yes, when they are built carelessly. Authorisation design, input validation, API permissions and testing all matter. A custom screen that bypasses permissions you set carefully elsewhere, or an integration account with wider access than it needs, quietly undoes good governance. Ask who reviewed the security design, not only who wrote the code.Why do ERP upgrades require additional testing when customisations are involved?
Because every extension is a dependency. A new version may change something the extension relies on, so each one needs compatibility checks and regression testing against your real processes, plus a recovery plan if something fails. The more extensions you have, the longer that list gets.When Is Custom Development Actually the Right Decision?
Sometimes building is exactly right. It is justified when a documented requirement cannot be met adequately through standard functionality, when a specialist workflow creates measurable operational value, when the available add-ons are unsuitable or bring unacceptable dependencies, and when there is an agreed plan for maintenance, documentation and testing. Take away that last condition and even a good idea becomes tomorrow’s liability.How should a SAP Business One agency justify custom development?
Five criteria work well as a gate. Business necessity: what breaks without it. Alternative assessment: what was tried first and why it fell short. Cost-benefit analysis: build and running costs set against expected value. Technical feasibility: whether it can be done safely on your version. Long-term supportability: who maintains it, how it is documented and what happens at upgrade. If an agency can answer all five in writing, the proposal deserves a serious look.How Should a SAP Business One Agency Decide Between Configure, Integrate, Add-On and Customise?
This is the sequence worth asking any agency to follow when a new requirement lands.New business requirement
Document the outcome, the users and the process. ↓ then check-
Standard SAP Business One
-
Configuration
-
Integration
-
Supported add-on
-
Custom development
What Questions Should You Ask Your SAP Business One Agency Before Approving Custom Development?
Take these into the next scoping meeting. They also work as a scorecard: give each answer 2 if it is clear and documented, 1 if it is vague and 0 if there is no answer. A run of zeros tells you more than any single response.- Can standard SAP Business One already meet this requirement?
- Have configuration options been evaluated?
- Is there a supported add-on that provides the capability?
- What measurable business problem will the development solve?
- What are the implementation and annual maintenance costs?
- How will the solution affect future SAP B1 upgrades?
- Who owns the documentation and the custom code?
- How will the solution be tested and supported?
- What happens if we change our SAP Business One agency?
- Can the development be removed or replaced later?
How Can You Reduce Existing SAP Business One Customisations Without Disrupting Operations?
If you already have a heavy extension layer, you do not need to tear it out. Work through it in order.Step 1: Audit existing add-ons, scripts and custom workflows
List every extension, the process it supports and the person who owns it. Include the small scripts and scheduled jobs, which are the ones people forget.Step 2: Identify unused, duplicated or high-maintenance functionality
Check usage, ownership, cost and dependencies. Something nobody has opened for a year is a candidate for retirement. Something three other processes depend on needs care.Step 3: Compare existing customisations with standard SAP B1 capabilities
Ask whether current standard functionality or a configuration change could replace each bespoke piece. A short, hypothetical inventory shows how the outcome can look.| Extension (hypothetical) | Purpose | Finding | Decision |
| Purchase approval app | Routes large purchase orders | Overlaps standard approval procedures | Test a configured replacement, then retire |
| Two reporting add-ons | Management reports | Duplicate functions, two licences | Keep one, migrate the reports |
| Stock-ageing script | Monthly stock view | Rarely run, owner left | Check against standard inventory reports before retiring |
| Web order sync script | Moves orders into the ERP | Fragile, undocumented | Replace with a supported integration |
| Regulatory export | Statutory file for authorities | Needed, works | Keep and document |
Step 4: Test proposed changes in a separate environment
Cover functional testing, integration testing and user acceptance testing, and agree a rollback plan before anything goes near live data.Step 5: Build a phased ERP simplification roadmap
Start with low-risk changes, and do not remove critical functionality without validation. Simplification that stops invoices going out is not simplification.When Should You Ask Another SAP Business One Agency to Review Your ERP?
Repeated upgrade failures, support costs that keep climbing, developments nobody has documented, or a disagreement over whether a piece of custom work was ever necessary all justify a second opinion. A good independent review should give you an inventory of extensions, a risk assessment, fit-to-standard findings, remediation priorities and an estimate of effort. Ingold Solutions is an SAP Silver Partner with ISO 9001:2015 certification, and works across SAP Business One implementation, integration, add-ons and ongoing support. It also develops its own certified extensions, such as an E-Commerce add-on and a Contract Management add-on, which is exactly why the questions in this article apply to any agency, Ingold included. If you would like a second view of your own setup, the team can talk you through what an assessment or implementation review would involve for a system of your size and complexity.Final Thoughts: Your SAP Business One Agency Should Simplify ERP, Not Complicate It
A successful SAP Business One project is not measured by how many custom features were delivered. It is measured by process efficiency, reliability, user adoption and how easily the system can be maintained in five years. The right agency does not recommend the most development. It recommends the least complexity necessary to achieve the business objective.Not sure whether your SAP Business One system has become unnecessarily complex?
Speak with Ingold Solutions about reviewing your existing ERP setup, integrations and development requirements. You can reach the team through the contact page.Frequently Asked Questions
Often, largely yes. Many businesses run on standard functionality plus configuration, adding specialist tools only where a real gap appears. Whether that works for you depends on your processes and version, so ask your agency to demonstrate the standard features against your requirements before any development is proposed.
Configuration uses what the product already offers: settings, permissions, approval templates, workflows and queries. Customisation adds new functionality through development, such as an add-on or custom code. Configuration is generally quicker to change and easier to carry through upgrades, which is why it should normally be considered first.
Usually it does, because every custom element needs support, documentation, testing and compatibility checks. The increase is justified when the feature delivers clear value. It becomes a problem when the feature duplicates standard functionality or nobody can explain what it saves. Track the running cost of each customisation, not just the build cost.
Yes. Extensions and integrations may depend on parts of the system that change between versions, so they need compatibility checks and regression testing. Simple additions such as user-defined fields tend to be lighter than complex add-ons. Ask for a list of extensions and their test status before choosing an upgrade date.
Ask whether standard features and configuration were evaluated first, what measurable problem the build solves, and what it will cost to keep. If the agency cannot answer clearly, or every change arrives as a quotation, a second opinion is reasonable. The ten questions earlier in this article give you a structure.
Often yes, but carefully. Audit what exists, find what is unused or duplicated, compare it with standard capabilities and test replacements in a separate environment first. Retire items in phases and keep a rollback plan. Never remove something that supports a statutory or financial process without validating the replacement.
Where a supported add-on meets the requirement, it is usually worth considering first, since it is maintained for many customers rather than one. Check compatibility with your version, licence costs, vendor support and overlap with tools you already run. If it fits poorly, custom work may still be the better route.
Often, provided there is documentation and clarity on code ownership. A new agency will usually start by inventorying the extensions and assessing risk before taking on support. Missing documentation or locked source code makes the handover harder, which is why ownership terms are worth settling before development begins.
Applicable for Package
Optional