Interview
Interview with
What is Aeco Legal Tech doing?
Aeco is a startup offering digital transformation services to the legal industry. Depending on the digital maturity of an organisation, we offer different solutions. Our most advanced offering consists of an API where an organisation with in-house developers can directly leverage our tax model. This so-called “Tax API” provides programmatic access to (tax) legislation and is a world premiere in offering tax services to corporations. This allows corporations to programmatically access tax regulations and use them across their business in a digital and integrated way. Potential use cases are internal as well as external and can range from simple calculations to complex optimisations.
Instead of each business custom developing internal tools, they can now use Aeco’s robust foundation and algorithms to boost their digital offering. This allows them to jumpstart their innovative business models and gain a competitive advantage without having to worry about programming and maintaining the tax legislation.
Why did you decide to build an API?
An API essentially means that people can use your technology directly, without the need for custom applications and front-ends. For us this means that our already existing tax model can now be leveraged without the need for an Aeco developer to intervene.
What is the API doing exactly?
The API is an interface to our in-house developed tax model. This is a mathematical model that contains many relevant Belgian tax legislation, knows how to link them and use them for calculations and optimizations. For example our model can answer questions such as:
- How much social security contribution should somebody that lives in Leuven, with two children and an income of 50K pay?
- Is it beneficial for a self employed person to start a one man company?
- Should a self-employed person use fixed costs or real costs?
What were your main challenges while building the API?
The hardest part was, and still is, the documentation. Both using an API and tax legislation can be complicated. When you put them together things get even more complicated. We need to find a balance between giving the user flexibility with our tax model and not overwhelming them with options.
How did you get the info you needed to start building an API?
One of our co-founders is a CTO of a technology company. He knew exactly which frameworks would fit our needs.
Who are example consumers of your API?
Currently, we focus on companies providing accountancy and tax software, larger accountancy firms, financial institutions and insurance brokers. However, the goal is to reach anyone who wants to add value to their existing products and services by adding tax calculations and insight.
Other potential users include universities that can leverage the api for research and development and governments who can use the API to improve evidence based decision making and tax policy.
I read that you created documentation; how did you approach that?
Writing good documentation is a challenge in and of itself. So you need a good framework to make things easier. We used the python framework FAST API, which is an alternative to the popular Flask framework. FAST API combines code with documentation: while you are developing your different endpoints, documentation will be automatically generated containing information about which data types to expect in the request and the response. Also the docstring comments from your python file will be converted into markdown documentation that is readily available in the docs.
Are you thinking of monetizing this API?
The aim is to keep the API free for everyone until they are monetizing the service themselves. A great example is our cooperation with Bothive, a communication platform for accountants. They use our Tax API to incorporate a gross to net calculator in a chatbot. Our pricing is based on a pay per use which scales easily with their business model.
How do you control whether companies are monetizing the service or not?
The free version does not come with any guarantees about uptime and accessibility. If you are monetizing your service you probably want to be sure that our service is available: if you want this guarantee, you will need to pay.
Also we monitor our API closely. If we have a huge spike in usage, we can track this down to see where this is coming from. If it turns out that this is a commercial service, we can contact the owners.
Do you have plans to build other APIs or enlarge the scope of this API?
Definitely. We will gradually increase the number of legislation accessible through the API. Also we are looking for a way to extend the current documentation with documentation that is relevant for non technical readers. By doing this, legal experts and developers can start from the same source, and once things get too technical a developer can refer to the precise documentation of the endpoints. For the implementation of a more extended documentation we are looking to the docusaurus 2 framework.
Any other recommendations you would like to share with the API community Belgium or entrepreneurs thinking to provide services via APIs?
- Make sure that your API is not “blind”: you need to know who is using your API, how they are doing this and when things go wrong. At Aeco we use firestore for logging API requests, sentry for error monitoring and a custom integration with google chats to notify our developers instantly when errors occur.
- Test your API regularly: our tax model is written in python and we use the pytest library to test our endpoints on a recurring basis. Also each time an update or bugfix is performed, all end-points are tested.
- Try to get to know your users: when an API key gets requested we first ask a couple of questions to see what kind of people are using our services. At the end of the day, all the technical details do not matter one bit if you are not providing an added value to your users!