What you need to know about edge cases when it comes to small business data.
When building integrations, there’s a long list of ever changing differences that need to be monitored and standardised to eliminate painstaking manual verification as well as potential errors. Standardised data is crucial for software providers and financial institutions. This is because it makes it so much easier to build integrations with accounting tools using a single computing interface, or API.
In this article, we take a look at some of the edge cases and scenarios that must be considered in order to successfully maintain a complex data model and develop robust integrations.
What is a data model?
A data model organises elements of data across various data sources and standardises how they relate to each other to enable easily accessible data.
Why is maintaining a data model hard?
When building integrations, there are many pitfalls which lie in waiting. It’s essential to consider as many edge cases and scenarios as possible, in order to avoid these traps.
There’s no doubt that data types differ greatly between financial platforms, varying in structure, complexity, and approach. For example, bookkeeping terms, like revenue and turnover, vary between geographies and different accounting platforms. This makes the data standardisation process one of the most complex aspects of integrations.
Codat has built up a deep repository of knowledge and understanding with integrations across several business domains including accounting, commerce, and banking, which are built into our ever expanding data model.
Thousands of data sets flow through our platform on a daily basis. This has enabled us to develop substantial experience handling the many challenges maintaining a complex data model presents. Our team of experts proactively monitor and handle any changes made to the format of the financial platforms we support; we sort, convert, rewrite, and rework all the data until it is fully compliant with the standardised format.
What are edge cases and scenarios?
When it comes to integrations, it’s crucial to constantly consider ‘what if this happens?’ to minimise the chances of an end-user interacting with the data in a way that renders the whole integration buggy at best or useless at worst. To understand the significance of this consideration, let’s take a look at an example.
In both commerce and accounting domains, taxes are commonly applicable. Codat’s integrations include a lot of tax data on both commerce (e.g. sales) and accounting (e.g. invoices). However, it’s not always easy to determine the tax code applied to a sale, as it may depend on multiple factors, such as:
- The integration package behaviour – QuickBooks may not calculate taxes in the same way as Xero. The intricacies of each accounting package need to be understood.
- The data itself – Some integrations may offer tax amounts as opposed to others offering tax percentages. Some may be generous and offer both. Some integrations may surface this data automatically, calculations may be required for others.
- Real world – Tax is different across geographies. For example, US sales taxes are different to other countries and even vary significantly from state to state. Take the following example of where you may find varying data across different regions:
- Sourcing (Origin vs. Destination) – Where a sale is taxed.
- NOMAD States – Tax exempt states.
- Nexus – Relationship between state and business.
- Type of Nexus – Affiliate Nexus, Economic Nexus, Click Through Nexus, Physical Presence Nexus, Marketplace Facilitator and Remote sellers.
Our point is simple, why waste time and resources reinventing the wheel of integrations when Codat can take care of all of this for you?
Sharang Shandil, Technical Business Analyst
You can start building with Codat for free today. Visit pricing to find the right plan for you or or explore our docs to find out more about our data model.