SAP Business One add-on vs customization: how to choose.
What we build.
Configuration first
User-defined fields and tables, formatted searches, queries, alerts and approval procedures: the lightest changes, often done without writing a program.
Database-side validation
SBO_SP_TransactionNotification procedures that check or block a transaction before it is saved, written for SQL Server and SAP HANA.
UI API add-ons
Native SAP Business One screens, menus and events for processes the standard client does not have, packaged for the Extension Manager.
DI API and Service Layer work
Programs that create or update documents and master data through supported SAP interfaces, instead of writing to tables.
Review of existing customizations
We read what is already in your system (fields, queries, procedures, add-ons) and tell you what is upgrade-safe and what carries risk.
A written recommendation
A short proposal that names the lightest option that meets the requirement, with a fixed price per phase if building is needed.
See also: Custom SAP Business One add-on development · SAP Business One development
Built for teams like yours.
Companies deciding whether a requirement needs an add-on or only configuration
Companies comparing third-party add-on suites with custom development
SAP Business One partners who want a second opinion on a customer’s customization plan
How a project runs.
- Requirement: a free call to understand what the business needs to do and what SAP Business One already does.
- Lightest option first: we check whether configuration (fields, searches, queries, alerts, approvals) meets the requirement.
- Recommendation: a written comparison of the realistic options for your case, with upgrade safety, effort and maintenance for each.
- Build, if needed: fixed price per phase, weekly demos, testing on a test company before production.
- Handover and support: 3 months of free post-go-live support, and you own the code.
What counts as customization in SAP Business One?
Customization is any change to how SAP Business One looks or behaves for your company. It ranges from light configuration to programs. Light: user-defined fields and tables, formatted searches, queries and alerts, approval procedures and print layouts. Heavier: stored procedures that run during transactions, add-ons built with the UI API or DI API, and integrations through the Service Layer.
An add-on is the heavier end of that range: a program with its own screens or logic, installed through the Extension Manager. The useful question is not "add-on or customization" but "what is the lightest option that meets the requirement and that we can keep maintaining".
When is an add-on the right choice?
An add-on is the right choice when configuration cannot do the job: a process needs its own screens (plant maintenance, payroll, a scan-to-document workflow), logic spans several documents, or data must be created in SAP Business One from another system. If a field, a search or a query is enough, use that first.
A third-party add-on suite can be a good fit for needs that many companies share. A custom add-on is a better fit when the process is specific to you, or when you want to own the code. Compare support terms and update schedules before deciding either way.
Which changes are upgrade-safe?
User-defined fields and tables and formatted searches are supported configuration in SAP Business One. TransactionNotification is a supported SAP hook, but it runs inside every transaction, so keep it fast and test it after each upgrade. Add-ons that use the UI API, DI API or Service Layer rely on supported interfaces, which is safer than touching the database, though each should be retested on a test company before an upgrade.
SAP does not support direct writes to its tables. Changing SAP data with SQL can bypass checks and break consistency, so write through the DI API or Service Layer instead.
What can you solve with configuration before building anything?
Quite a lot: extra fields and tables with UDFs and UDTs, auto-filled values with formatted searches, reports and alerts with Query Manager, and validation with a TransactionNotification procedure. Try these first, because they are the cheapest to change and the easiest to move through an upgrade.
Move to an add-on when you hit a limit: you need a new screen, the logic needs a program rather than a query, or an external system must write into SAP Business One.
Who owns the result and who maintains it?
Ask this for every option. Configuration lives in your company database and can be maintained by your SAP partner or your team. A third-party suite is maintained by its vendor under its licence terms. A custom add-on from Kodenova is built at a fixed price per phase, comes with 3 months of free post-go-live support, and you own the code, so you can continue with your own team or your SAP partner.
Add-on vs customization: decision table
Effort and maintenance are relative (low, medium, high) and depend on your case. Upgrade safety describes how the option sits in relation to SAP-supported interfaces; every option should still be tested on a test company before a SAP Business One upgrade.
| Option | Good for | Upgrade safety | Effort | Maintenance | Developer needed? |
|---|---|---|---|---|---|
| UDF / UDT | Extra fields and small custom tables on standard screens | High: supported configuration | Low | Low | No for fields; often yes for UDOs |
| Formatted search | Auto-filled and validated field values from a query | High: supported configuration | Low | Low to medium (queries need testing after a database change) | Helpful: needs SQL |
| Query Manager queries and alerts | Reports, lists and notifications | High: read-only queries | Low | Low to medium | Helpful: needs SQL |
| TransactionNotification procedure | Blocking or checking a transaction before it is saved | Medium to high: a supported SAP hook, but it runs inside every transaction | Medium | Medium (keep it fast and tested on every version) | Yes |
| UI API add-on | New screens, menus and form logic in the SAP Business One client | Medium: depends on the forms and events it uses | High | Medium to high (retest on each SAP Business One version) | Yes |
| DI API add-on or service | Creating documents and master data from code | Medium to high: uses the supported object model | Medium to high | Medium | Yes |
| Service Layer integration or extension | Web, mobile and system-to-system integrations, portals | Medium to high: supported REST interface | Medium to high | Medium (API version, authentication, session limits) | Yes |
| Third-party add-on suite | Common needs that many companies share | Depends on the vendor and its release cycle | Low to medium | Medium (depends on the vendor’s update schedule) | Usually no |
Direct writes to SAP tables with SQL are not in this table on purpose: SAP does not support direct writes to its tables, so they should be avoided.
SAP Business One add-on vs customization: common questions
What is the difference between an SAP Business One add-on and a customization?
Customization is any change to how SAP Business One works for you, from user-defined fields and queries to programs. An add-on is the program end of that range: a separately installed extension with its own screens or logic. Many needs are met by lighter customization, so check configuration before building.
Are UDFs and formatted searches upgrade-safe?
User-defined fields, tables and formatted searches are supported configuration in SAP Business One, so they are the lowest-risk customization. Formatted searches contain SQL, so test them after a database change, such as a move from SQL Server to SAP HANA, and after an upgrade.
Is SBO_SP_TransactionNotification safe to use?
It is a supported SAP hook, but it runs inside every transaction of the types it checks. Keep the procedure fast, avoid heavy queries, test it on SQL Server and HANA syntax, and retest after each upgrade. Used for focused validations, it is a good lightweight alternative to an add-on.
Can I write directly to SAP Business One tables with SQL?
SAP does not support direct writes to its tables. They can bypass validation and leave data inconsistent. Reading with queries is normal; for creating or changing documents and master data use the DI API or the Service Layer, which apply SAP’s business rules.
Should I buy a third-party add-on suite or build a custom add-on?
A suite suits needs that many companies share and you want quickly. Custom suits a process specific to your business, or when you want to own the code. Compare update schedules, support terms and whether the suite is tested on your SAP Business One version before you decide.
Do add-ons break when I upgrade SAP Business One?
They can, because forms, events and objects may change between versions. Add-ons built on supported interfaces are the safer kind, but any add-on should be tested on a test company copy before a production upgrade. Kodenova includes 3 months of free support after go-live and offers upgrade testing afterwards.
Who owns the code of a custom add-on from Kodenova?
You do. Source code, database scripts and documentation are handed over at the end of each paid phase. You pay a fixed price per phase, so you can continue with your own team or your SAP partner, or ask Kodenova to keep supporting it. Kodenova is independent and works alongside your SAP partner.
SAP Business One development
Any add-on your business needs: plant maintenance, payroll, approvals, warehouse, integrations and reports for SAP Business One.
SAP Business One integrationSAP Business One API integration
Service Layer and DI API integrations between SAP Business One and banks, logistics and couriers, marketplaces, CRMs, payment gateways and other systems.
SAP Business One supportSAP Business One development support and retainer
After the 3 free months: a monthly retainer for bug fixes, SAP B1 upgrade testing, HANA compatibility, small changes, new reports and integration monitoring.
Ready to get started?
Tell us what you need. You get a clear technical answer, a fixed scope and a price, usually within 24 hours.
