How a decision-tree rebuild of Tradeshift’s original invoice coding engine is pushing customers from touchless in theory to touch-free in practice
In 2017, when most of the accounts payable software market was still selling rules engines and static templates, Tradeshift shipped Ada: an AI-powered engine that learned how a company coded its invoices and started doing it for them. There was no “AI wave” to ride yet. Generative AI wasn’t part of the enterprise vocabulary. We built Ada because manual invoice coding was, and still is, one of the most repetitive, error-prone tasks sitting inside every AP team’s day.
Ada has quietly done that job for years, embedded in the workflows of major enterprise finance teams, coding invoice and credit note lines based on historical patterns, supplier data, and user input. It worked. But “it worked” is not the same as “it scales,” and as our customers grew, so did the complexity we needed Ada to handle. You can read more about Ada’s capabilities here.
In November 2025, we shipped Ada 2.0, a rebuilt engine that is changing how customers move from touchless in theory to touch-free in practice on invoice processing. Here is the story of why we rebuilt it, what actually changed under the hood, and what it means for the AP teams using it today. If you want the deeper engineering account of that rebuild, our Director of Engineering wrote about the journey from Ada 1.0 to Ada 2.0 when we entered Beta.
✨ Tradeshift has been building AI-powered AP automation since 2017, years before generative AI made “AI-powered” a line item on every vendor’s pitch deck.
Why the original engine had to be rebuilt
Ada’s first version ran on a Naive Bayes model: a simple, fast statistical approach that made predictions based on patterns in item descriptions, suppliers, and other key invoice fields. For a first-generation AI product in 2017, that was genuinely ahead of the market. But a Naive Bayes model makes one big simplifying assumption: that the features it looks at are independent of one another. Invoice coding doesn’t work that way. The right account code for a line item often depends on a combination of factors together, not any single one in isolation.
As our customer base grew more complex, three pressures made that assumption harder to live with:
- Coding decisions increasingly depended on combinations of features (supplier, tax treatment, currency, cost center) rather than any single field, which a Naive Bayes model isn’t built to capture well.
- Customers change vendors, update coding lists, and adjust tax logic constantly, and the model needed to adapt to that faster than a static statistical approach allowed.
- Some customers have thousands of account codes on their coding lists, and the original architecture wasn’t designed for that scale of label space without a performance cost.
Those weren’t reasons to patch Ada. They were reasons to rebuild it from the ground up. That rebuild is Ada 2.0.
From Naive Bayes to Decision Trees: what actually changed
Ada 2.0 replaces the original statistical model with a decision tree classifier. If you’re not an ML engineer, here’s the plain-language version: instead of judging each field on its own, a decision tree works the way a trained AP reviewer does. It weighs several pieces of information together, in sequence, following the logic of “if this, and this, then that” until it lands on the most likely code. That structure captures the interdependence between fields that Ada’s original model couldn’t.
Practically, this shows up in a few concrete engineering decisions:
A dedicated model per company, per coding list.
Instead of one general-purpose model, Ada 2.0 trains a separate model for each company and coding list pair, using that company’s own historical coding data. Your Ada is trained on your invoices, not a generic dataset.
Better generalization across diverse datasets.
The new algorithm holds up better when a customer’s invoice population is varied, rather than degrading as diversity increases, which is exactly the scenario that stressed the old model.
A single API call.
The prediction process is streamlined into one API call, which simplifies integration for our engineering partners and reduces the operational surface area we have to maintain.
Backward compatibility.
Ada 2.0 is backward compatible from a functionality standpoint, so customers already relying on Ada didn’t have to change how they work to benefit from the upgrade.
None of this required customers to rebuild their workflows. It required us to rebuild the engine underneath them.
What Ada 2.0 actually changes for AP teams
Higher accuracy compounds into fewer touches
Better generalization and per-company modeling both point at the same outcome: more of Ada’s suggestions are right the first time. That matters more than it sounds, because invoice exceptions are rarely a single-step problem. An incorrect code doesn’t just need correcting, it needs to be caught, routed, reviewed, and re-approved. Every percentage point of accuracy Ada 2.0 gains removes a chain of manual steps downstream of it, not just the one prediction.
Automation rates stay up as your supplier base grows
A model that generalizes well doesn’t get worse as your invoice population gets more diverse. That’s the practical difference between touchless in theory and touch-free in practice: a system that holds its accuracy steady as you onboard new suppliers, enter new markets, or restructure your coding lists, instead of one that needs constant retuning to keep up.
Your team decides how much AI does
Ada 2.0 doesn’t force an all-or-nothing choice between full automation and manual review. Administrators can set confidence thresholds that determine how many invoices and credit notes get auto-coded versus routed to a person, and can adjust that dial as trust in the system grows. Coupled with the Automation Dashboard, teams get a clear, ongoing view of how much of the coding workload AI is handling versus manual processing, so the shift toward automation is measured, not assumed.
The engine covers more of the invoice lifecycle
Version 2.0 extends beyond straightforward invoice lines to also handle PO and non-PO invoices with varying levels of PO reference, and credit notes, including cases where the original invoice being credited is missing. It also plugs into Ada’s other coding-adjacent skills: matching supplier profiles during onboarding to prevent duplicate records, suggesting the right person to route a document to next, and classifying products and services into UNSPSC codes to support spend analysis. Coding is the core of Ada 2.0, but it sits inside our broader AI-powered AP Automation platform, where it works alongside the rest of the automation the platform already handles.
Why we’re telling this story now
Ada 2.0 has been in the market since our Fall Release, first in Beta and now moving toward general availability, and the response from customers has validated the two years of engineering work behind it. Teams retesting the same invoice sets they’d run against the original Ada are seeing the improvement in accuracy directly, which is often the clearest signal that underlying technology has actually moved forward, not just been repackaged.
What we hear most consistently in these conversations is a shift in framing: teams stop asking whether AI can code invoices reliably, because they’ve already been running Ada for years, and start asking how much further they can push automation now that the engine underneath it is meaningfully stronger. That’s a different, and more valuable, conversation than the one most AP teams are having with AI for the first time in 2025.
A name with a longer history than most AI products
Ada was named as an homage to Ada Lovelace, widely considered the first computer programmer, back when we launched the original engine in 2017. Ada 2.0 continues that lineage: a next-generation invoice coding engine that keeps learning from every user action, the same way the original did, just with a fundamentally stronger foundation underneath it.
What’s next
Ada 2.0 is not the end state, it’s the foundation for what comes after it. On our roadmap, Ada’s coding and matching capabilities are converging with our newer AI Document Intelligence work, which uses OCR and large language models to read invoices without needing a template in the first place. Extraction and coding are two halves of the same problem: getting a document into your system correctly, without a human doing it by hand. As both continue to mature, alongside the broader agentic AI vision we’re building across Tradeshift, from AI Reporting & Analytics to AskAda for Sellers, the direction is the same: finance teams spend less time managing the mechanics of AP, and more time on the judgment calls that actually need a human.
Ada started before the AI wave existed. Ada 2.0 is what happens when a team keeps building on that head start instead of resting on it.