Few UK finance directors start a Sage project wanting to write code. They start with a process that does not quite fit: an approval chain that follows the company's own authority limits, a customer-specific invoice layout, a report the board asks for every month. Whether that gap is closed by a setting, an extension or Sage development makes a lasting difference to cost, risk and the effort of every future upgrade.
This page sets out the options in the order you should try them, explains what each does to your upgrade path, and finishes with a practical way to assess the people proposing the work. It applies whichever Sage product you run; the exact tools differ by product and release, so confirm them with your partner for your own version. For the wider picture, see our overview of Sage ERP.
Sage customisation: four levels, from safest to riskiest
The useful way to think about Sage customisation is as a ladder. Every step up gives you more freedom and costs you more to maintain.
| Level | What it means | Effect on upgrades | Typical use |
|---|---|---|---|
| Configuration | Using options built into the product | Normally none | Chart of accounts, VAT codes, user rights, document layouts, approval rules |
| Reporting and workflow tools | Building reports, dashboards and routing rules with supported tools | Low; reports occasionally need checking | Management packs, exception reports, internal sign-off |
| Existing extensions and add-ons | Adding a product written by a third party or by Sage | Depends on the supplier keeping pace with releases | Specialist needs such as sector-specific features |
| Bespoke development | Code written for your company | Highest; every release needs retesting | A genuinely unusual process or integration |
Most UK SMEs and mid-sized businesses can meet the large majority of their needs on the first two rungs. The discipline is to climb only when the rung below has been tried properly and found wanting.
Level one: configuration done properly
Configuration is not a lesser option. In a well-run project it is where most of the value sits. It covers the structure of your nominal ledger, analysis codes for cost centres and projects, customer and supplier terms, VAT treatment, user roles and the approval rules that mirror how your business signs off spend.
Two points matter in the UK context:
- Tax settings are configuration, not code. VAT schemes, reverse-charge handling in sectors such as construction and the data needed for Making Tax Digital should be handled through supported settings and the product's own submission features wherever they exist. Writing code around tax rules is a sign something is wrong, because the rules change and your code will not change with them.
- Payroll follows the same logic. Real Time Information submissions and statutory calculations are best left to the standard payroll functions. See our page on payroll and RTI and the Sage-specific page on payroll and HR.
Poor configuration is also the usual cause of requests for development. A business that has not set up analysis codes sensibly will ask for a bespoke report to do what a code structure would have done for free.
Level two: reports, forms and workflow
Before anyone writes code, look at what the supported reporting and workflow tools can do. Many requests that sound like "personalisation of Sage" turn out to be a report layout, a sales order confirmation that carries different wording for different customers, or a notification when a credit limit is reached.
These tools have two advantages. They are designed to be used by finance and operations staff with some training, so changes do not always need a developer. They also sit on supported interfaces, so they rarely collide with upgrades. The cost is discipline: reports multiply quickly, and a company that has grown a large library nobody owns has simply moved its technical debt into a different place. Name an owner for each report and retire the ones nobody opens.
Level three: existing extensions and add-ons
The Sage ecosystem includes products from independent software vendors that add features the core product does not have. Examples include specialist functions for particular trades, extra document handling or tools that connect Sage to other systems. Our page on Sage integrations covers the connection side in more detail.
Buying an extension is usually cheaper and faster than building one, but it brings its own dependency. Ask the supplier:
- which Sage releases the add-on supports today, and how quickly it follows new ones;
- whether it is maintained actively, and what happens to your licence if the supplier is acquired or withdraws it;
- how it behaves when you upgrade, and whether the partner has installed it elsewhere on your version.
An abandoned add-on is one of the commonest reasons a Sage upgrade stalls. Treat it as a supplier relationship, not a one-off purchase.
Level four: Sage development for genuinely unusual needs
Bespoke development is justified when the process is a real source of competitive advantage, when no extension exists and when the standard product genuinely cannot be bent to fit. A manufacturer with an unusual costing method, a distributor with a pricing model driven by contract terms, or a services firm with a billing rule specific to its clients can all have legitimate cases.
What you can build, and in what language, depends on the Sage product and its release. Some products expose published interfaces that let external code read and write data under control; others provide their own development environment. Rather than assuming, ask your partner to name the tools they would use for your version and why. A partner who cannot explain that in plain terms is not ready to quote.
What a good development approach looks like
A competent Sage developer will usually work in the following way:
- Specify before building. A written description of the business need, the expected behaviour and the test that proves it works. If the specification is a sentence in an email, the project is already at risk.
- Stay on supported extension points. Use the interfaces the vendor documents rather than altering the way the product works internally.
- Isolate the custom code. Keep it clearly separate from the standard product so that it can be identified, removed or replaced.
- Version and document it. Source control, a readable description of what each piece does and a record of who changed what.
- Test against each release. Before you upgrade in production, the custom code is checked on a copy of your data.
If you are weighing whether to build a module sur mesure for Sage, in other words a bespoke module, ask first whether the process could be simplified. Many bespoke modules exist because a business copied an old spreadsheet routine into the new system instead of questioning it.
What customisation does to updates and upgrades
The cost of customisation rarely shows on the day it is delivered. It shows two years later when a new release arrives.
- Configuration is stored as data and is generally carried forward.
- Reports and forms may need a quick check after the upgrade.
- Add-ons depend on the supplier's compatibility statement.
- Bespoke code has to be retested in full and sometimes adapted, particularly where the vendor has changed an interface it depends on.
This is why the sensible default is to stay as close to standard as the business allows. Every bespoke element is a commitment you will pay again at each upgrade, and the commitment grows as more of it accumulates. Ask your partner to keep a register of everything that departs from standard, with a short reason for each and an estimate of the upgrade effort in qualitative terms such as low, moderate or high. That register is one of the most valuable documents in a Sage project, and it is the first thing a new partner will ask for if you ever change supplier. Our page on Sage versions and editions explains how release choices interact with this.
Hosting matters too. Where Sage runs in a hosted or cloud arrangement, the room for modifying the product can be narrower and the vendor's release rhythm may be less negotiable. Check this early; the hosting and cloud page sets out the questions to ask.
Best practice: stay standard, document, test
Three habits separate a Sage system that ages well from one that becomes a burden.
Stay standard wherever it costs you little
Challenge each request with a simple question: what will it cost us if we change our process instead of the software? Often the answer is almost nothing, and the benefit is a system that upgrades cleanly and that new staff recognise. Keep customisation for what is truly specific to your business.
Document as you go
Documentation is not an end-of-project chore. For each customisation, record the business reason, the owner on your side, what it does, how it was built and how to test it. Store this somewhere your company controls, not only in the partner's files.
Test with real scenarios
Tests should reflect how your business works: an invoice for a customer with special terms, a purchase order that crosses an approval limit, a month-end close, a VAT return run. Ask for the test scripts to be handed over so that your team can rerun them after each upgrade. The implementation and training pages cover how testing and user adoption fit into the wider project.
How to evaluate a Sage developer or integrator
Whether the work is carried out by an independent developer, a small consultancy or a larger integrator, assess them on method rather than on enthusiasm. These questions are a good start.
| Question | What a good answer sounds like |
|---|---|
| How do you decide between configuring and coding? | They describe the ladder above and can name cases where they talked a client out of development |
| How is custom code kept separate from the standard product? | A clear explanation of extension points, isolation and version control |
| What happens when we upgrade? | A defined routine: test on a copy, fix, retest, then go live |
| Who owns the source and documentation? | You do, or the terms are explicit and written down |
| What if you are unavailable? | Documentation and handover arrangements, not reassurance |
| Can we speak to a business with a similar need? | They offer references without being asked twice |
Be cautious of anyone who promises that any requirement can be met quickly, who quotes without understanding your process, or who is reluctant to discuss ownership of the code. Equally, be wary of a partner who never recommends development; sometimes it is the right answer, and a good partner will say so and explain why.
Because Sage skills in the UK vary widely between small specialists and larger integrators, it helps to compare more than one proposal. Our guide to choosing an ERP integrator and the Sage-specific page on choosing a partner give you a checklist. If you are inheriting a heavily customised system that is already in difficulty, an independent audit and project rescue is often the sensible first step before more code is added.
When customisation points to a different product
Sometimes the volume of customisation you need is itself the answer. If most of your core processes depart from standard, you may be forcing a product into a role it was not designed for. That does not necessarily mean Sage is wrong, but it justifies comparing alternatives honestly. Our page on Sage alternatives and the comparisons of Odoo and Sage and Business Central and NetSuite show how other platforms approach extension, which differs in important ways between them.
Getting a proportionate proposal
A good brief makes everything else easier. Before you contact any Sage partner, write down which processes do not fit, what each costs you today in time or errors, and which could reasonably change. Rank the gaps by importance. Partners will then propose in order of value, and you will avoid paying for development that merely reproduces habit.
If you would like help finding a Sage integrator who works in this disciplined way, our free introduction service puts you in touch with a suitable firm for your project, whether you are in London, the North West, Scotland or anywhere else in the UK. The integrator carries out the work; we make the connection and stay neutral between vendors.
Frequently asked questions
What is the difference between configuring Sage and developing on it?
Configuration uses options the product already provides: fields, workflows, document layouts, permissions and rules. Development adds code that the standard product does not contain. Configuration normally survives an upgrade untouched, whereas code has to be retested, and sometimes reworked, every time the underlying release changes.
Will a Sage customisation stop me upgrading?
Not by itself. Problems come from changes that reach into the core of the product instead of using its supported extension points. A well-built extension, documented and tested against each release, upgrades with modest effort. A modification of core behaviour is the kind that makes every upgrade a small project.
Do I need a bespoke module, or is there already an extension for it?
Check in this order: standard configuration, then reporting and workflow options, then an existing extension or add-on from the Sage ecosystem, and only then bespoke code. A good Sage partner will try to prove that the need cannot be met more simply before quoting for development.
How do I judge a Sage developer or integrator before hiring?
Ask how they separate custom code from the standard product, how they document and version it, how they test against a new release and who owns the source afterwards. Ask for the reasoning behind a past decision to keep something standard. Vague answers on any of these are a warning.
Who owns the code written for my Sage system?
That is a matter for the contract, so settle it before work starts. State whether you receive the source, the documentation and the test scripts, and what happens if the developer stops trading or you change partner. Without those terms, your business can end up dependent on one supplier for a system it relies on every day.
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.