How can we help?

AzoraOne is an API service that allows you to enrich your accounting application with self-learning automation of data entry. Once the communication with the AzoraOne API has been properly set up, the fields in your application will be prepopulated with values in accordance with each user’s preferences. These values include numbers and words from the source document as well as the coding, i.e. the allocation of transaction amounts to accounts in the chart of accounts.

Note: While AzoraOne does automate data entry, its most distinct differentiating factor is the automation of the coding. When it comes to the coding, AzoraOne, to the best of our knowledge, is far ahead of the competition. Why? There are several reasons for this but the most important is AzoraOne's ability to build knowledge models on company level. In contrast to header/footer data, total sum and VAT (i.e. what you likely will get with legacy invoice processing solutions), the coding is highly subjective to the company at hand. Not only regarding choice of accounts, but also regarding the granularity of the data entered into the general ledger. So, to us, it has, from the very onset of our company, made perfect sense to build knowledge models on a company level - the key to achieve highly tailored extraction and coding.

The backbone of AzoraOne is a proprietary algorithm that generates effective prediction models on extremely small data sets. We have chosen to build and store these models on company level, i.e. every company serves as a basic container for the building of new models. When AzoraOne is activated on a company, we often refer to it as a robot.

Think of a new robot as a clean canvas. In order to learn, it will compare your booking with the corresponding source document and try to connect the dots, i.e. build a proposed model on how to collect the corresponding values from the next image. If successful in building such a model, the proposed model will be added to the robot's collection of models. Which also can be referred to as the robot's knowledge.

We use the term coding to describe the process of allocating a transaction amount to an account in the chart of accounts.

By source document we mean any document of relevance for bookkeeping from which you would want to extract data as well as assign nominal codes (e.g. cost accounts) to selected amounts. Examples are bills, invoices, receipts, bank statements, cash machine slips etc.

The robot will learn to:

1. Sort incoming digital source documents into document types and verification series.
2. Extract values from incoming digital source documents.
3. Code incoming digital source documents.

All in accordance with the specific company's historical bookings. 

The learning is instant.

If you bookkeep a document with values that can be found on the document, the next time a similar document (for example, a supplier invoice from the same vendor) is extracted, the data entry fields in your accounting software will likely be prepopulated with values in accordance with your previous booking. 

Obviously, the more granular the coding, the longer it might take for the robot to catch all items.

In order to derive value from classic foundation models you have to feed them with massive data sets. The result being generalized models with little or no room for customisation on individual or company level.

AzoraOne, on the other hand, requires so little data in order to be trained that we have chosen to generate models on company (i.e. customer) level. The models are continuously generated as bookkeep requests flow into the API. 

This continuous generation of models builds the foundation for highly customized extraction and coding on a company-level. That said, although the models are created on company-level, the API comes with the option to share and expand selected models to a larger set of companies (for information on how to implement this, check out the the progenitors resource). Which, in its turn, opens up a world of opportunities for let's say, an accounting firm that want to leverage work being done on one customer also on other customers. 

Considered that models (i.e. knowledge) are generated on company-level rather than population level, a brand new company robot must first build a model in order to generate value. In other words, you have to show the robot what values should be extracted from a source document and also how to code the transaction.

In the most basic scenario, you do this by just continue to register your transactions as you normally do after activating AzoraOne in your software. The robot will learn from your ordinary work, and it will learn fast.

However, there are several ways to take advantage of AzoraOne's superior learning capability in order to eliminate this initial knowledge gap. Among these:

1. upload historical bookings and source documents from the actual company (training a robot on 2000 different suppliers (yes, suppliers - not documents) in less than 15 minutes),
2. share knowledge between companies by the use of progenitors, or
3. use built up knowledge from other companies in the system to perform basic extraction (the result will be similar to population-generated models) to hit the ground running and evolve with company-specific coding and extraction.

What options that will be available to your customers depends on your accounting software's implementation.

The AzoraOne algorithms learn from bookkeep requests sent from your application. To ensure that the user's bookings will benefit the next extraction, it's important to extract the file when the user is about to register it in your application. Of course, you can choose to extract upon file upload, for example to populate a list of files with preliminary extraction data. But in order to avoid learning delays, it's essential to extract the file at the very moment when the user actually is going to handle it. 

Remember, AzoraOne builds models on document level. Which means that the pool of models is continuously updated with each booking. So extraction results are highly dynamic - a prerequisite to create the profound effect of rapid learning for the user. Which is one of AzoraOne's main characteristics compared to other services on the market. With other services (where the results are more or less static), performing more extractions than the initial is pretty much pointless.

The processing is performed in two steps:

1. File upload: Upon uploaded to the AzoraOne API, the file (e.g. a PDF invoice or a PNG receipt) is pre-processed so that the models that take care of the extraction and coding can do their work as efficiently as possible. This step includes OCR conversion of image to machine-readable text (when needed), structural rearrangement, normalisation of values and creation of fingerprint patterns. Depending on number of pages and volume of text, this step takes typically between 1-3 seconds.

2. Extraction: The extraction is the part of the processing that delivers the customer value. Once pre-processed, the file can be extracted as many times as you or your customer wants. Typically, a file would be extracted at least two times; once immediately upon upload and once when the user is ready to register the file in the ledger. The extraction of a file takes between 300-500 ms.

In order to automate coding by using a bank statement as the source, you have to set up rules manually for each vendor that might appear on the statement. When you do this, you have to make assumptions that must be correct for every future transaction on the vendor. If these assumptions are not correct, there will be incorrect information in the general ledger. To code straight from a bank or credit card statement can have short term benefit: no need to collect, sort, or process piles of receipts and invoices. However, you’ll always have a degree of guesswork involved in your bookkeeping entries as there are bound to be transactions each month that are not recurring, are from smaller, non-universally recognized suppliers, or require unique treatment. For example, when suppliers include multiple line items which need to be coded differently on a single receipt, working from the total amount in the bank feed prevents you from seeing the “whole picture”. Calculating VAT or taxes from the transaction total instead of reading them from the source file will inevitably lead to errors in VAT reporting. 

Regardless of the situation, not coding from source documents will make the bookkeeping error prone. Total and vendor just don’t cut it if you want accurate entries in the general ledger.

Coding from source documents will remove this uncertainty and feed the general ledger with accurate, precise data of the optimal granularity.

Within a month of making the decision to go with AzoraOne these things will happen:

• Your developers and product team have enjoyed a fast and frictionless integration 
• You have propelled your accounting software to best in class in the highly competitive category of bookkeeping automation 
• You have a solution that:
  • requires a minimum of maintenance and development 
  • has a predictable monthly cost
  • offers a new pipeline of content for your marketing and sales department 

And most importantly:

• You will have a solution that your users will love, driving demand and increasing retention

At Arkimera, we have five core beliefs that drive our development efforts and act as guiding stars in our decisions. You can call them our big bets, the things we believe will be decisive in the future of accounting tech. (On the surface, they may seem like general truths. However, when scrutinized, all go against conventional wisdom when it comes to the area of bookkeeping and automation.) 

1. Automation by simplification erodes the foundation for informed business decisions

If you want to predict the future, you need to understand the present. And if you want to understand the present, you need to know the history. 

The general ledger has traditionally been the fountain to tap into if you want to know the history of a company. Today, when many accounting software solutions allow for real time bookkeeping, the general ledger will also deliver the present state of a company. Which gives excellent opportunities to predict the future. 

Provided, of course, that the data in the general ledger is abundant enough and granular enough. Decreasing the resolution in the chart of accounts does the opposite of that; it erodes the foundation for advisory and informed business decisions. Which is why we believe that most of today’s automation solutions will lead you trapped in a dead end in a future where data will be gold also in the context of bookkeeping. 

2. Not all companies have the same needs, a one fits all approach to automation doesn't cut it

If you want to go beyond simple extraction of header and footer data from supplier invoices and receipts, you must use an automation strategy that can handle the different needs of different customers. Machine learning models built on population data just don’t cut it if you want to be able to automate according to a company’s specific needs and preferences. We see it as a watershed moment: Forcing people to adapt to technology or developing technology that adapts to people? For us, the answer is a no-brainer. 

3. Coding is key

Automation that doesn’t deliver coding is only semi-automation. If you can’t deliver the coding, automation of other bookkeeping documents than supplier invoices will pretty much be limited to a date, VAT and a total. And, regardless of document, the challenge for a business owner or a bookkeeper is not to enter an invoice number, a due date or a total; the challenge lies in the coding. (And knowledge doesn’t solve it all: consistency is key, both in choice of coding accounts and level of granularity.)

4. Niche is a good thing

Building self-learning technology that complies with the first three bets above is quite a task. Although we have great respect for what Xero, Intuit and others have accomplished in the area of accounting software, despite thousands of developers and millions of dollars plowed into AI and machine learning, they have no solution in place that solves the above. Honestly, bank feed rules may seem smooth, but without close monitoring and diligent follow up, they inevitably lead to incorrect VAT reporting and a loss of granularity in the general ledger. Vendor and a sum just don’t cut it. And prediction models based on population data inevitably lead to flawed one-fits-all solutions.

We believe that the future of accounting lies in plenty of structured, high quality data of the right granularity – automation is just the means to an end. So, for us at Arkimera Robotics, continue building our self-learning technology and leave bank feed rules and machine learning models based on population data to others is probably the best bet we can take. 

5. Treat accountants and bookkeepers as gold 

Why? Because they are experts. They have the knowledge and experience needed to decide on the optimal resolution of the charts of accounts for any given business. Which also translates to the right level of detail in the coding of a given transaction. By empowering them with the right technology, the right amount and resolution of data in the general ledger can be obtained. Which builds the feeding ground for meaningful analysis, reporting and benchmarking. 

Where others spend resources and energy to find out how to bypass the accountant in the bookkeeping process, we have a different aim. At Arkimera, we see:

 the Expert's work + self-learning technology = mutual value-generating loop 

The bookkeeping process will be automated, we don’t differ in that opinion. But rather than rely on simplifications and rule settings, we believe in leveraging the expert’s knowledge and experience. Which will lead to a huge difference in end result. 

Paving the ground for a future where the general ledger provides the optimum amount and detail of structured data to generate next-level reports, benchmark analyses and key performance indicators. Our belief is that the accountant of tomorrow will go from generalist to niche expert - and be able to charge more, not less, for automation of data entry and compliance work. While building the foundation for the advisor role.

So, these are our five big bets. As you can tell, we don't strive to be everything to everyone. Instead, we strive to build alliances with individuals and organisations that believe in what we believe in: Bookkeeping as the foundation to informed business decisions.

Over the coming five years, we expect a shift in how accounting data is produced, consumed and valued. The core driver is simple: machine-driven bookkeeping can deliver more data of higher quality to a lower cost than traditional bookkeeping. As high-quality transactional data becomes increasingly central to forecasting, planning and decision-making, businesses will demand systems that generate both accuracy and depth by default.

Today, that is not the reality. After years of investment in automation, the market still largely operates with semi-automation – achieved by lowering data resolution and simplifying complexity. The result is weaker data, questionable ROI and continued manual dependency.

We believe the market will move towards fully automated and truly reliable accounting flows capable of delivering precisely the right resolution for each business’ needs. The large incumbents have talked about full automation for a long time. The coming years will be about delivering it. 

From the very start, our approach has centred on coding logic that adapts to each company’s needs and behaviour. This gives us a structural advantage and puts us ahead of the curve. However, full automation requires one more leap — and we are now taking it.

With Smart Contracts (newly released, in beta), we believe we have assembled the key components needed to deliver a fully automated, failproof solution. Although still early, Smart Contracts already offer a glimpse of a future where accounting logic becomes a networked ecosystem – creators earning across platforms and standardisation emerging organically from the market itself.

We see the next five years as a move from labour-intensive workflows to autonomous, data-rich, standardised accounting processes. With Smart Contracts built on top of our machine-driven modelling engine, Arkimera is positioned not only to respond to industry changes but to lead them.

In the basic scenario, upon creation of a new company, no models exist on that company - model-wise (or knowledge-wise if you so prefer) the company is a clean canvas. A canvas ready to be paint not by pencil and colour but with bookkeeping requests. The model generation (i.e. the learning) will be instant, perform a first bookkeeping request and a model will be created. Upon your second extraction on a similar file, you will likely receive a response populated with values.

In most cases, the account rows will not balance in a valid bookkeep request sent to the supplierinvoices endpoint. If the account rows balance and you get an error message from the API, you have most likely included the amounts for total sum and vat in the account rows. Which you should not, these values should be added to the parameters totalSum and vat, respectively. Thus, it's the values on totalSum, vat and account rows that must balance. On totalSum and vat, positive as well as negative values can be posted. If a positive value, the totalSum will be calculated as a credit post. If a positive value, the vat will be calculated as a debit post. Only absolute values should be sent on account rows; as debit posts if positive and as credit posts if negative. 

These parameters can be used to specify a time frame for the inheritance of knowledge. Meaning that progenitor models created only during this specific time frame will be added to the competition of models on the inheriting company. An example might be an accounting firm making a concentrated effort to perform extremely consistent bookings on selected customers from a planned start date. By adding these selected customers as progenitors to new and existing customers (that share the same chart of accounts and coding regimen) and set the startDateTime to the actual start date of the concentrated effort, all the inheriting customers will benefit from the concentrated effort performed on the selected few. An example on when to use the stopDateTime might be during holiday season when temporary work force may be used, thus increasing the risk of inconsistent bookings. Interestingly enough, the latter can be attenuated to a large extent by implementing AzoraOne - prepopulated fields in accordance with historical bookings (i.e. AzoraOne's promise) lessens the probability for inconsistent bookings.

AzoraOne is consumed exclusively through our REST API, and our customers integrate it directly into their own accounting or automation platforms. Because our customers differ significantly in how they package and bill their services, we provide flexible pricing models rather than a single public price plan.

We align our billing with your technical and commercial architecture. Models include:

• Per-file
• Per-company / per end-customer
• Tiered usage levels based on monthly or annual volume

This gives you the ability to match our price structure to your own customer pricing without needing to redesign your product offering.

A fixed price plan would not accurately represent the diversity in integration patterns among our customers. Our customers range from small vendors to companies 100× our size, each with different API call patterns, pricing strategies and end-user volumes.

Instead, we agree on a model that matches:

• Your customer's expected API throughput
• Your business model (SaaS, module-based, usage-based etc.)
• Your end-customer volume and growth projections

This ensures predictable costs while maximizing the value you deliver to your users.

That said, although the billing model varies, most customers converge toward an effective rate between €0.05 and €0.10 per processed file.

Let's start with what AzoraOne doesn't do:

• AzoraOne doesn't rely on historical postings, customer-specific rules and/or fuzzy-logic field matching to determine GL coding.
• AzoraOne doesn't have any configuration elements like predefined mappings between extracted terms and nominal accounts or customer-specific definitions of which value combinations should trigger accounts.

Rather than defining configuration-heavy rules that specify which values matter, AzoraOne automatically identifies the relationships between document values, contextual anchors and nominal codes based on how each company books its documents.

For every booked document, AzoraOne generates a document-specific model that captures how the accounting outcome was derived. Over time, the company accumulates a pool of models that describe its actual accounting behaviour. When processing a new document: 

• if the user historically booked line-item values, the model learns to reference those 
• if the user booked on subtotals, grouped costs or VAT components, the model learns those instead 
• if multiple anchors jointly determine the posting, the relationship is learned automatically 

Hence, with AzoraOne, there is no manual definition of which value combinations the system should remember. No customer or implementer needs to decide and configure which value relationships to capture. No customer or implementer needs to maintain these relationships over time as document patterns evolve. Instead, the relationships are extracted from real postings and refined continuously as users validate or adjust results. 

It would probably be a very good fit. For example, AzoraOne doesn't require historical data upload, manual configuration or ongoing updates as document patterns shift. Which means close to zero onboarding and maintenance. Instead, AzoraOne reconstructs the user’s accounting logic automatically by identifying which document values led to the booked outcome, then generates document-level models without requiring any rules or mappings to be specified. 

The latter creates a self-updating, company-specific modelling pool that reflects real accounting behaviour and evolves without manual configuration effort. Which is ideal for micro businesses and SMEs where low document volumes makes configuration-heavy solutions a non-option.

No initial data needed.

AzoraOne doesn't require users or implementers to define or maintain value-to-account mappings per customer. AzoraOne identifies these relationships automatically.