- Briefcase — Blog
- Posts
- 💼 Introducing 'Contextual Learning' in the world of AI Accounting
💼 Introducing 'Contextual Learning' in the world of AI Accounting
How to teach an AI to do accounting
Generative AI has the capability to deliver huge efficiency gains, but foundational models are trained on publicly available data and don't have the specific business knowledge that accountants need. This is a barrier to widespread AI adoption in accounting, where individual business context is crucial to understanding how to process transactions according to specific client needs. In this post, we explore the solutions available and introduce ‘Contextual Learning’ as our preferred approach.
[Read time: 7 minutes]
🤕 Understanding the problem
The current state-of-the-art accounting platforms rely on rule-based automation, which has fallen short of delivering significant productivity improvements in the last decade.
Don’t believe me? Check for yourself (or ask your accountant) what percentage of transactions you are autopublishing with Supplier Rules through Dext or how many transactions you are automatically processing using Bank Rules in Xero.
What are Supplier/Bank Rules?
Popular accounting platforms can facilitate end-to-end automation of specific workflows only when pre-determined rules are set up and maintained by the user.
For example, a supplier rule might be set up to ‘automatically’ categorise all Amazon transactions received to the ledger code 710 - Office Equipment.
In our user testing, the answer is normally in the single digits, around 7-9%. There are a few reasons why:
Set up: setting up supplier rules is a fully manual process that takes time. You have hundreds of clients, each with hundreds of suppliers, and you have to be careful not to accidentally set up the wrong rule for the wrong client or supplier. It’s a (very large) minefield.
Maintenance: once a rule is set up, it will run indefinitely, come rain or shine, unless you manually change or delete it. This is a problem when circumstances change (e.g. a customer starts using the same supplier for a different service which should be posted to a different ledger code), resulting in incorrect posting.
and, the most important, Lacking Context: there are many vendors you can never set up rules for. Amazon is a great example — anything can be purchased through Amazon nowadays, so it’s not good setting up a supplier rule to categorise all Amazon purchases as ‘Books’. Other data points might also impact this decision, such as the transaction amount: if a £15,000 taxi receipt gets uploaded, you probably want this to be reviewed by a human before automatically pushing it to the ledger.
GenAI is the antithesis of a rigid rule. With the right AI agent infrastructure, it can reason independently and adapt to different scenarios. It performs best when you feed it the necessary context, analogous to how a human accountant learns a client’s preferences when delivering work for them.
🎓 The traditional way of (machine) learning
Until recently, the way to make an AI context-aware was to train it on specific contextual data.
In the case of traditional accounting OCR vendors, this means a labelled dataset of specific receipts/invoices you want the model to understand well. This approach has many challenges, one of which is that the model lacks up-to-date information; it only works on use cases similar to those provided in the training dataset, and it is not able to adapt to new situations, such as unusual formatting or some foreign currencies.
In the case of new GenAI vendors, it meant fine-tuning a foundation model with accounting-specific data. This is very costly and time-consuming, and at the rate that generalised foundational models are improving, it is quickly becoming obsolete.
🏎️ Steering LLMs in the right direction with Contextual Learning
We believe the better approach is to use a generic model and feed it specific data. This allows you to benefit from the superior accuracy and reasoning capabilities of the newest and largest foundation models while also providing them with the context they need to complete tasks accurately. Since this is not learning in the traditional sense (i.e., not training a model), we call it ‘Contextual Learning’.
Another huge benefit of this approach is that it is fast and scalable. This is very important in accounting because every customer needs to be treated differently depending on the context, as we’ve mentioned previously:
In our view, the key ingredient missing from current tooling is context. A crude example: if a coffee shop buys paint, it is probably for maintenance and repairs, but if a construction company buys paint, it is probably a cost of goods sold and should be categorised as such. LLMs are very good at digesting contextual data from multiple sources, understanding it semantically, and generating a reasonable response. The use case for categorisation is written in the stars (as long as you can get the ‘contextual data from multiple sources’ piece right: it is as much a data integration problem as an AI problem).
As such, if you wanted to deploy traditional learning, you would have to create a bespoke fine-tuned model for every customer with similar capabilities to today’s leading foundation models, which is not feasible due to the cost. Not to mention that it would take much longer to develop and would be rendered out of date as soon as OpenAI releases the next version of GPT.
To be explicit, this also means that we do not share data across clients or practices when deploying our AI agents.
Treating accounting as a big data problem and generalising across customers from different industries has been tried before, but it doesn’t work because every customer receives different accounting treatment based on their specific circumstances.
Bookkeepers and accountants often do this subconsciously — e.g. ‘for this client, we only consider fixed assets above £250, but for that client, the threshold is £500’.
Contextual Learning can be achieved for every customer at scale by building custom embeddings with your client-specific data. In practice, this means an embedding model is mapping the client data (‘context’) to a vector database to understand the semantic relationship between fields.
In case I’ve lost you, here’s an example… imagine the data in question is simply a collection of words and the task is to group the words into similar categories. Custom embedding would allow you to draw a multi-dimensional map of words that are similar to each other in semantic meaning. This means “dog” and “cat” would be closer together on the map than they are from the word “table”. Now if the word you had to categorise was “chair”, the model would be able to recognise to put in the “table” category, not the “dog” and “cat” category.
I’m making a few jumps here; but in bookkeeping, you could imagine the categories you are mapping to are ledger codes and the words are invoices. In practice, when a new invoice is received, we would retrieve similar labelled invoices from that client’s vector database, and feed these into the foundation model to steer it in the right direction.
There you have it. That’s the playbook to go from 7-9% automation to 70-90% automation and 10X the productivity of an entire industry.
🤔 What’s next?
The same principles can be applied to other accounting workflows, such as management accounts (month-end), tax, and year-end accounts (working papers). In fact, by starting with bookkeeping, you can build a context-aware system that retains a high level of data enrichment and is, therefore, better placed to automate downstream accounting services.
The challenge, which will form the core IP of our platform, is building a novel data platform that is able to ingest and disambiguate real-world client data and AI agents that can use this data to automate tasks with high accuracy and auditability.
Data platform: We will need to integrate with multiple data sources to enrich every transaction with the necessary context to process it accurately. This will include email integration, historical ledger transactions, bank feeds, internet searches, and more. Real-world data is often conflicting, and building a robust data pipeline that can resolve these conflicts will be a significant technical challenge.
AI agents: The infrastructure for agentic AI workflows is still in its early stages. As an emergent technology, we are positioned at the forefront of the AI application layer, working to deploy what could be this decade’s most transformative technology in an incumbent-led industry that is ripe for disruption.
Thank you for joining us on this journey. Subscribe to stay informed on our latest updates.
Interested in learning more? Get in touch (by replying to this newsletter or reaching out on LinkedIn).
Until next time 🫡
Reuben