Sage 50 Accounts is still the set of books behind a lot of established UK businesses. Not the newest ones, which mostly start on Xero or QuickBooks Online, but the firms that have been trading for fifteen years, have a bookkeeper who knows Sage inside out, and see no reason to move.
If you build software that those businesses use, for expenses, purchasing, credit control, stock or field service, sooner or later one of them asks whether you work with Sage 50. The honest answer is usually “sort of”. There is a CSV template, or a Windows app they have to install, or a consultant you can introduce them to.
This post is why that is, what the real options are, and what I am building about it.
Why there is no API
Sage 50 Accounts for the UK and Ireland is desktop software. The data lives in files on a Windows PC or server, in the office or on a hosted desktop. There is no Sage-run cloud service holding a copy, so there is nothing on the internet for another product to call.
Sage’s own developer team has said as much on its forum: there is no supported API for the UK product. Xero and QuickBooks Online have one because the books live on their servers. Sage 50’s books live on yours.
The routes that do exist
There are four, and it is worth knowing the shape of each before choosing one.
- Sage Data Objects (SDO). The official way to write data into Sage 50: posting invoices, creating customers, recording payments. It is a Windows component that runs alongside Sage on the same machine or network, and it comes with Sage’s developer programme, quoted publicly in 2023 at £2,500 plus VAT a year.
- The ODBC driver. Installed with Sage 50 and free to use. It is perfectly good for reading: reporting, exports, dashboards. It cannot post anything.
- SData. A local web service that ships with Sage 50. From version 28 the adapter is a separate install. It looks like a web API, but it is still running on the Sage machine, not somewhere you can reach from the cloud.
- Third parties. Unified API companies such as Codat cover Sage 50 for some uses, mostly lending, with a connector installed on the customer’s PC. Others sell a REST add-on that the business installs on its own server. And there are integration firms who will build the whole thing for you, usually with a setup fee and a monthly charge.
The thread running through all four: something has to run on the machine where Sage 50 lives. Every Sage 50 integration is, underneath, a small Windows program that somebody has to install, keep running and update.
What that means if you build software
I spent some time looking at how UK software companies handle Sage 50 today, and the pattern is consistent:
- Several well-known spend management tools offer a CSV template. The customer exports from one system and imports into the other, by hand, every time.
- At least one approvals tool says plainly that Sage is not supported yet.
- Others have built their own Windows connector and maintain it themselves. One asks customers to uninstall and reinstall it for every update.
- Ecommerce platforms mostly leave it to middleware, at something like £500 to set up and £150 a month, paid by the business.
None of those is wrong. They are what you do when the alternative is a Windows project that never quite ends. As far as I can see from the outside, the hard parts are these:
- Sage releases a new version every year, and the connector has to keep up with each one.
- The PC gets switched off at half five. Anything that writes to Sage has to queue and wait, and say so clearly, rather than fail.
- Hosted desktops change everything. A lot of Sage 50 runs on remote desktop servers or with hosting providers, and the connector has to go there, not on anyone’s laptop.
- Writing is the expensive half. Reading is easy and free. Posting an invoice means SDO, the developer programme, and a lot of care, because these are someone’s real books.
What I am building
It is called Daybook: a hosted REST API for Sage 50 Accounts, UK and Ireland.
The idea is the one that already works for QuickBooks Desktop in the US. The business installs one small connector on the machine that runs Sage 50. It only makes outgoing connections, so there is nothing to open in the firewall. Software companies then call ordinary HTTPS endpoints for customers, suppliers, invoices, payments and the nominal ledger, and Daybook handles the rest: Sage versions, queuing when the PC is off, and hosted setups.
It is priced per connected Sage 50 company, so a software company pays for the customers who actually use it.
What it is not
It is not made by Sage or affiliated with Sage in any way.
It does not cover Sage 50 in the US or Canada, which are different products that happen to share a name.
And it is not live yet. I am talking to software teams first, so what gets built first is what they actually need rather than what I guess they need. That is what early access is for.
If you build software
If your customers ask about Sage 50 and the current answer is a CSV, have a look at daybookapi.com and tell me what you would need on day one. The first ten teams get it at half price for a year in return for a monthly call about what is missing.
If you run a business on Sage 50
You do not have to wait for any of this. Connecting Sage 50 to a shop, a CRM or a stock system is the sort of custom integration I build today. Get in touch or email [email protected].
Sage, Sage 50 and Sage 50 Accounts are trademarks of The Sage Group plc. Daybook is an independent product and is not affiliated with, endorsed by or sponsored by Sage. The developer programme price is as quoted publicly in 2023; check with Sage for current terms.