Customising SAP Business One: from configuration to bespoke development

Almost every company that adopts SAP Business One asks the same question in the first workshop: can it be made to fit the way we work? The honest answer is yes, within limits, and the real decision is how far to go. SAP Business One development ranges from a few extra fields on a sales order to a full bespoke module with its own screens and logic. Each step up the ladder brings more flexibility, but also more cost, more risk and more to maintain for years.

This page sets out the options in order of weight, explains how each one interacts with upgrades, and gives you a practical way to assess the person or firm proposing the work. It is written for UK finance directors, operations managers and IT leads who will have to live with the result long after the consultants have left.

The customisation ladder in SAP Business One

Think of customisation as a ladder. You should climb only as high as the requirement forces you to.

Rung one: configuration and the built-in tools

SAP's own implementation training presents a set of customisation tools that sit inside the product. They include user-defined fields, user-defined tables, user-defined objects and user-defined values, alongside SQL queries, alerts and approval workflows. None of this involves writing a program in the traditional sense.

In practice this covers a great deal:

• an extra field on a customer record for a delivery restriction or an account-manager reference;
• a query that lists overdue orders for a given branch or region;
• an alert that warns the credit controller when a customer passes an agreed limit;
• an approval workflow that routes purchase orders above a threshold to a second signatory.

Because these tools are part of the application, they are designed to survive upgrades. A good consultant will push most requirements down to this level first. If you are comparing proposals, the one that solves more with configuration is usually the safer one. Our page on setting up SAP Business One explains where this work fits in a typical project.

Rung two: existing add-ons and partner solutions

Before anything is written from scratch, check whether someone has already built it. SAP states that Business One is distributed through a large partner network, with more than five hundred industry and country extensions. That figure comes from SAP's own announcement of December 2025, which also mentions hundreds of partners worldwide.

An existing solution has three advantages over bespoke code. It has been tested by other customers, it has a vendor whose business depends on keeping it compatible, and it usually costs less than writing the same thing again. The trade-off is that you adapt your process to the product rather than the other way round, which is often a healthy discipline.

Typical candidates include sector-specific functions, specialist reporting, document management and tools for particular trades. Our overview of SAP Business One modules is a good starting point to see what the standard product already does before you look further afield.

Rung three: integration work

A frequent reason for development is not a new function but a connection: a web shop, a carrier, a bank feed, a time-recording tool, an external payroll bureau. SAP describes an Integration Framework as part of Business One, available on premise and in the cloud, which serves as a development and runtime environment for integration scenarios such as dashboards, mobile apps, outsourced payroll and web services.

Integration is development in the full sense. It has to be monitored, it breaks when the other system changes, and someone must own it. See our page on SAP Business One integrations for how to scope it sensibly.

Rung four: bespoke development

When none of the above is enough, a developer writes code. The main technical routes are these.

SAP's help documentation says the Service Layer runs on SUSE Linux Enterprise and on Microsoft Windows, uses the Apache server as a load balancer and can be deployed in embedded or distributed mode. It shares object definitions with the DI API through a common component, so both routes see the same business rules. SAP Learning adds that it supports Basic and OAuth authentication and is intended to make web and mobile development easier.

For a buyer, the technical detail matters less than one point: bespoke code written against these documented interfaces is a recognised practice, while code that reaches directly into the database is a warning sign.

Licensing and tooling: what is already included

A common worry is that development tools are an expensive extra. According to SAP's licence guide, user licences automatically include the implementation version of the Software Development Kit, the SDK tools, SAP add-ons, the add-on compatibility licence and the workflow, each for an unlimited-style ceiling of 99 999 users. They do not need to be requested separately.

That does not mean development is free; the labour is the cost. But it does mean you should not accept a quotation that treats basic tooling as a chargeable line. For the wider cost picture, see our guidance on SAP Business One pricing.

What customisation does to upgrades

Every customisation is a promise: someone will make sure it still works after the next update. The risk depends on where the change sits.

• Configuration lives inside the application's own structures and is the least likely to cause trouble.
• Third-party add-ons depend on the vendor's release discipline. Ask how quickly they certify against new versions.
• Bespoke add-ons depend on you and your developer. Without documentation and tests, each upgrade becomes a small project.
• Direct database changes are the riskiest of all and should be refused.

Upgrades also interact with your choice of version and hosting. Our pages on versions and editions and on support and maintenance explain how to plan for them. A sensible contract states who tests customisations before an upgrade, on which environment, and who pays if a fix is needed.

Good practice for UK businesses

Stay as close to standard as you can

Standard processes are cheaper to train, easier to support and simpler to replace people on. Before agreeing to a change, ask what the business would lose by adopting the standard behaviour. If the honest answer is "a little convenience", leave the standard alone.

Document everything that is not standard

For every field, query, workflow and piece of code, someone should record what it does, why it exists and who asked for it. This is the single habit that most separates tidy systems from fragile ones. Keep the documentation in your hands, not only in your supplier's.

Test on a copy, with your own people

Customisations should be tested on a separate system filled with realistic data, by the users who will rely on them. Your finance team should confirm how a change affects VAT treatment, and your payroll administrator should confirm anything that touches pay data.

Be careful with statutory requirements

UK compliance moves on a timetable you do not control. If a requirement relates to Making Tax Digital or to payroll submissions under Real Time Information, do not assume a bespoke build is the answer. Our guides on Making Tax Digital and ERP software and on payroll software and RTI explain what to check, and your accountant should confirm what your business must submit. A maintained solution is nearly always better than code that only one person understands. For the local picture, see SAP Business One in the UK.

Do not customise to avoid training

Some requests are really requests to avoid changing habits. A change in process, supported by training, often costs less than a change in code.

How to assess a developer or integrator

A strong SAP Business One developer behaves differently from a weak one long before any code is written. Use these questions in your selection process.

1. What would you not customise? A good answer names areas where they would advise staying with standard behaviour.
2. Which interfaces do you use? They should name the SDK, the Service Layer or the Integration Framework, and explain why one fits your case. Anyone who proposes writing straight to the database should be questioned hard.
3. How do you separate development, test and live? There should be a clear route from one to the next.
4. What documentation will I receive? Ask for an example from a past project with client details removed.
5. Who owns the code? Make sure you can move to another firm without a dispute.
6. What happens at upgrade time? You want a named process, not a reassurance.
7. How do you support the module after go-live? Look for a defined response, not goodwill.

Our page on choosing a SAP Business One partner widens these questions to the whole project. If you already have a heavily customised system and doubt its health, an independent audit and project rescue can tell you what is worth keeping.

Common warning signs

• A proposal that lists many bespoke features and few configured ones.
• No mention of testing, documentation or upgrade handling.
• A fixed attachment to one individual developer who holds all the knowledge.
• Customisation used to replicate the old system screen for screen.
• Reluctance to explain how the work is priced or who owns it.

Any of these is a reason to pause and ask again.

Next step

If you are unsure how much of your requirement is configuration and how much is genuine development, describe it in our request form. We match you with an integrator suited to your sector and size; the integrator carries out the project, and the introduction is free. Our page on how the matching works explains the process.

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.