A developer’s guide to building a Sage 50 integration

An overview of the process of building a Sage 50 integration, the pitfalls to look out for, and how to ensure the best results for you and your SMB customers.

Sage 50 is a desktop accounting software with advanced functionality for small businesses. It offers a comprehensive set of features, including invoicing and expense tracking, inventory management, VAT compliance, payroll processing, financial reporting, and bank reconciliation. 

Sage 50 is one of the top 10 accounting platforms for businesses. It has been widely used by UK businesses for a long time and is particularly important if you are targeting the UK and Irish markets. However, its popularity isn’t limited to these regions, as it reportedly has around 400,000 business customers worldwide.

Integrating with Sage 50 comes with several challenges and considerations, from overcoming network problems to navigating user installation permissions and accounting for potential user errors. In this post, Codat’s expert engineers explain the process of building a Sage 50 integration, the pitfalls to look out for, and how to ensure the best results for you and your customers.

On-premise vs. cloud software

The first important consideration is that Sage 50 is an on-premise platform, similar to QuickBooks Desktop (QBD), which will add complexity to your build.

An on-premise setup requires in-house server hardware, additional software licenses, advanced integration capabilities, and ongoing tech support. Your developers will need an intricate knowledge of accounting and bookkeeping to understand the relationship between data in the underlying database tables. They’ll need a strong understanding of how accounting data behaves and be familiar with Microsoft’s Component Object Model (COM) as well as the programming language of your choice (Visual Basic .NET, C++, C#, etc.).

It’s also important to note that desktop application development requires a different approach to building cloud systems. The interface isn’t the standard HTTP used for online integrations, so you may need to hire for some alternative skill sets. For example, most engineers will be used to HTTP calls/REST APIs, so you will either need to recruit specifically for this integration or upskill your teams.

The Sage 50 API integration process in three steps

The initial process of building a Sage 50 API integration can be broken down into the following three steps:

1. Create a Developer account

First, you need to create a Developer account, which you can do either using your email or your existing GitHub account (detailed instructions here).  It’s important to note that Sage keeps its products separate. So, even if you’ve built to Sage packages (such as Sage Intacct) in the past, the process will be different. You will also be charged separately.

2. Build the connector

Since Sage 50 is an on-premise system, access to the data is limited to the devices on which the software is installed or those connected to the same local server. So, your Sage 50 integration will need a direct connection between the system and the end user’s local data file. The good news is that building a Sage 50 connector is slightly more straightforward than the process for QBD since you’re not required to install an SDK alongside the application. 

Here’s a summary of the process:

At Codat, we use Open Database Connectivity (ODBC) to pull data and the Sage 50 SDK to push data (this is installed with Sage, so we don’t have to do it). Using ODBC connections for querying data is faster, but we don’t recommend using it for altering data as it can pose security risks. Plus, when altering data through an ODBC connection, errors may not be handled effectively, leading to issues such as data corruption or incomplete transactions. Instead, we suggest using the Sage 50 SDK, or a combination of the two. 

Note: The ODBC connection also requires a Sage 50 login. We recommend creating a separate account for this since you can’t use an account that’s being used by someone else, as it blocks you from syncing. 

This process is made easier with Codat. Clients can set up a Sage 50 integration by simply enabling it in the Codat Portal. Your customers can then download Codat’s connector, which runs as a Windows application, allowing you to push or pull data directly to your customers’ Sage 50.

3. Install the connector on users’ machines

Once you’ve built your connector, the next step is to help users install it on their machines. This step requires user input, which inevitably leads to errors. That’s why it’s essential to ensure the connection process is as simple as possible and that any errors can be identified and dealt with quickly.

Codat clients benefit from a pre-built installation journey. The SMB downloads the connector as part of the link flow, which requires them to complete just a few simple steps (such as inputting their license key). This conversion-optimized flow ensures a hassle-free installation experience for your customers.

Once this step is complete, our connector doesn’t require any further user interaction or administrator privileges; it runs in the background, starting up automatically after reboots. All updates are performed automatically and silently. Developers building without Codat’s help will need a solution to account for this.

Key considerations for building a Sage 50 integration

Sage 50 API documentation

Unlike most other accounting platforms, Sage 50’s API documentation isn’t openly accessible and comes with a fee. To access it, you need to fill out a form on the Sage 50 website and create a Developer account. Our Developers have found parts of the documentation to be outdated. That said, you do get some docs along with each SDK version, and their knowledgebase can be a helpful source of information.

Note: Supporting multiple versions on Sage can be difficult. Each separate version uses a different dynamic-link library (DLL) that contains identical classes but they don’t inherit from any shared resource. Developers building without Codat’s help will need to ensure they keep up to date with the latest Sage versions so their desktop app is up to date with relevant support. 

Data structure

Unlike most other integrations, Sage 50 doesn’t have pre-made API endpoints you can simply build to get data. Instead, you query the Sage 50 database to access the data, meaning data storage and access considerations will likely differ from your other integrations.

This can also cause other challenges. For example, if you wanted invoices from QuickBooks Online or Xero, building in-house to these two endpoints is relatively straightforward; both have their own native invoice API endpoints. 

Sage 50, on the other hand, stores everything in tables. It’s up to you to know which tables (and which columns in these tables) you need and how these tables join together. For example, if a lender wants to access an applicant’s balance sheet via Sage 50, they would need robust accounting and Sage 50 database knowledge to construct the balance sheet.

At Codat, our team of Analysts handle the hard work of identifying and accessing the right data, so you can focus on making use of it.

Accounting anomalies

Sage 50 has certain anomalies that are unique to the platform. For example, it displays unusual behavior when it comes to bank accounts. Usually, a bank account is considered an asset on the balance sheet. This is the case even if it has a negative balance when it is categorized as an asset with a negative value. However, in the case of Sage 50, a bank account with a negative balance is categorized as a liability with a positive value. 

Variations between accounting packages like this can cause developers considerable confusion, especially when knowledge of accounting principles and how accounting data behaves is limited.

We’ve spent years perfecting our standardized data model, which works across many accounting platforms, so developers don’t have to worry about these differences.

Testing your Sage 50 integration

Before deploying your custom Sage 50 integration, it’s important to conduct thorough testing in a controlled environment. Sage 50 provides a sandbox that lets you identify and rectify any issues before introducing the integration to live data.

Note: Your developers will need to install Sage on their machines to do this, and E2E environments will also need to be configured to diagnose and troubleshoot issues effectively.

How Codat helps

We have worked with Sage 50 for years. Our architecture has been battle-tested at scale and handles millions of requests daily across our platform. During this time, we have acquired a deep expertise, allowing you to deliver a superior integration experience to your customers without headaches.

Resolving your challenges is our global technical support team’s top priority. Trained to be highly specialized in accounting concepts and the API behavior of platforms like Sage 50, our team will act as a bridge between you and the underlying platform. This way, we can ensure the smoothest possible process and ongoing maintenance of your Sage 50 API integration.

Want to learn more about integrating with Sage 50?

Get in touch with Codat using the form below to chat with our expert team and get your questions answered. 

You can also jump into our docs to review the details of our business data APIs—or check out our full guide to building best-in-class accounting integrations for your app.