An introduction to API data standardisation
What makes data standardisation so complex and why is it crucial that it’s done right?
The development of Open Banking regulation in the UK (PSD2) and innovation in API technology has enabled financial institutions to access real-time, consented financial data from their customers’ accounting, banking and commerce systems, saving them time, facilitating better decision making and even reducing risk.
However, one notable challenge remains – how can financial institutions ensure the data being fed into their risk models by the countless different financial software providers their customers use is standardised?
Necessity – what is data standardisation and why do we need it?
In the realm of financial software, data types vary significantly – especially when sourced from different locations. For example, the bookkeeping terms used often varies between accounting platforms (e.g. revenue vs. turnover).
Standardised data is crucial for financial institutions. This is because it makes it so much easier for them to build integrations with accounting tools using a single computing interface, or an API.
When money is at stake, having absolute confidence in the inputted data is essential. To ensure this, a data standardisation process must be put in place.
Therefore, data standardisation is arguably one of the most important and complex processes when a customer contributes their data to their provider via an API integration.
The challenge – why is data standardisation so complex?
Different accounting platforms run on all sorts of different data types, varying in structure, complexity, and approach.
On top of this, each accounting platform may have its own philosophy regarding how such data should be displayed to their customers. And so, the standardisation process is a great leveller in this somewhat chaotic playing field.
So, what are the areas calling for thorough standardisation?
Let us take a look at a few obvious examples:
- Different ways of handling and displaying data across platforms. For example:
- Bills are surfaced in Xero as accounts payable invoices and in MYOB AccountRight as four different types of Bills.
- Bank accounts are not separated from other account types in QuickBooks Desktop or Xero and so require an additional layer of filtering to find these data points.
- Different requirements when pushing data to platforms, e.g. creating a customer in FreeAgent has different requirements to QuickBooks Online for a successful push of data.
- The differences between regional variations in date formats, of which there are a multitude.
- Different terms used in bookkeeping in different accounting systems (e.g. revenue vs. turnover).
- Different naming conventions for data fields as used in different integrations, e.g., “ID” in one solution is a “ref” in another.
- Different data formats (e.g. json vs. xml) used across integrations. This is the case when naming conventions could be the same and the target data is, essentially, the same, but the structures are so different that normalisation is needed.
- Different types of authentication approaches are used in integrations. Some have OAuth1, others OAuth2; some are based on having Usernames/Passwords, some utilise Private API Keys.
- Different rules of engagement for each accounting system, which, if not abided to, prevent use of their API for a period of time. These rules can vary between production and testing environments.
These issues in isolation may be manageable; but when combined they amount to something much more significant – a long list of ever changing differences that need to be monitored and standardised to eliminate the painstaking manual verification as well as potential errors.
Thousands of datasets flow through our platform on a daily basis meaning these types of challenges are handled and monitored by a dedicated team of experts at Codat regularly. We sort, convert, rewrite, and rework all the shades of data until it is fully compliant with the standardised format.
Following standardisation of data, entire integration ecosystems can be regulated, offering major performance improvements.
How our expert standardisation differs from the competition
Our API supports reading and writing to the ledger, with full accounts payable and accounts receivable support using our standardised model.
Our API does not place all ledger transactions into a single ‘bucket’, which would require our clients to understand the differences between every data point in each integration. Rather, we abstract and standardise data based on globally accepted accounting principles.
Our API ‘standardises’ an integration’s API limits so that you have peace of mind that you’ll successfully be able to call each integration. This means our API does not pass on, for example, the limits imposed by Xero to our clients. Instead, the Codat API seamlessly handles ‘cool down’ periods to ensure all calls are successful.
Sign up today to enjoy a 30 day free trial and see how Codat could enhance your business in a matter of hours.