Codat has expanded our support for pushing data into on-premise accounting software — now including Sage 50!
This release adds pushing suppliers and bills to Sage 50 with other data types to follow in coming months and builds on our experience in pushing data into QuickBooks Desktop which has now been used in production for over six months. For an up-to-date list of what software Codat supports pushing data to see our docs.
From the very beginning, Codat knew that we would need the capability to push data into on-premise accounting software.
The Sage 50 connector is one of our most popular accounting software connections but previously it was limited to only the extraction of data. Only supporting one-way data flows limits the value for small businesses of linking their accounting data with your organisation.
Even lending, a sector that has traditionally only used accounting data for decision making (a “pull” use case) is increasingly looking to provide a “push” functionality to clients.
That’s because small businesses who have a lending facility expect to have that facility automatically reported and reconciled in their accounting software, especially if they were required to link that accounting software during the application process.
This release is a step towards our public commitment to support pull and push of all datatypes for all the accounting software packages we support, together with five more in the next nine months.
—
Although we understood that we needed the capability to push data into on-premise accounting data, at the same time we also understood the challenges — especially when it came to pushing data into accounting packages that were inactive or offline.
We thought it would be a good opportunity to share our experiences of the challenges we faced in building these connections and how we have designed our solution to overcome them.
The challenges
There are many different elements to take into consideration when building to desktop software compared to the relative simplicity of developing to a cloud API.
Connecting to and interacting with software at a distance invariably comes with its challenges.
Below are examples of the many different factors that Codat must consider for each small business that may wish to connect:
- Physical machine
Is the computer running the software Windows or Mac? What spec of hardware? Which version of OS? We’ve even seen clients running on virtual machines in the cloud.
- Customisation of installation
Where is the programme installed? Is the data stored on the local PC itself or elsewhere e.g. a shared network drive?
- Accounting software version
Historic versions have different functionality, as do optional modules that can be added or enabled. For every new version of software that is released, typically every 6 months, the solution must be tested.
- Installation
There are often strict corporate policies in place that prevent installing software, anti-virus etc. How will your solution connect reliably?
- Connectivity
Software could be running on a laptop that might be turned off, possibly for weeks at a time. Internet connections are sometimes very limited for more rural businesses.
Our Solution
The idea was to build something that hides these complexities behind our single standard API, so that our clients can have the same experience as when they push data to a cloud accounting package.
Our solution involves a connector that small businesses install on their system which securely communicates with the Codat server at regular short intervals whilst the machine is turned on and connected to the internet.
The server keeps a record of all push operations that have been requested via the Codat API for each small business and when the connector is available, executes the queued insert operations.
This means we had to find a solution to the two engineering challenges created by the Connectivity challenge of integrating with software at a distance:
- Eventual consistency — This means that although a user of the API might have received a response from us right away, the operation requested may be completed some time later.
We built our API to allow monitoring of these operations right out of the gates. Especially around helping our clients understand quickly the “when and why” things might have gone wrong.
- Optimistic concurrency — This is a technical way of saying that we can’t always guarantee we are the only actor changing data in the system we are talking to. This means we might be trying to add data that has already been added, or altering data on the basis of out of date information.
We favour trusting the data provided by the user of our API, and we will only fail their requested operation if we believe the information they assumed when they called our API could be out of date at the point the operation is executed on the remote system.
To summarise
In order to effectively push data into desktop accounting packages you need to ensure you:
- Have a solution that can handle the many different versions, setups and connectivity of on-premise software installations.
- Build a secure connector that only you have access to, that calls server software at quick intervals.
- Handle cases where destination data has been updated or otherwise out of date since last available.
- Test your solution with each new version of on-premise software and operating systems that are released.
This is a hard problem to solve and requires dedication and time to get right. As a result of our hard work, today we are successfully and securely pushing data into thousands of small businesses’ accounting software each day.
Want to learn how to push data using the Codat API — read our docs or get in touch (info@codat.io) .
