What is the difference between RPA and document AI?
RPA, robotic process automation, executes steps that a person would also perform inside a system: click here, copy that, paste it into field X. The robot follows a script. This works well for fixed, repetitive actions where the input always has the same structure. Document AI does something different: it reads a document, understands the context, and extracts the right fields, even when the format changes. An invoice from supplier A looks different from one from supplier B, but document AI pulls the invoice number, amount, and payment terms from both. RPA would need a separate script for every layout.
When does RPA work well for document processing?
RPA is at its strongest when the document is not really a document at all: a structured export from a system, an EDI message in a fixed format, or a spreadsheet that always has the same columns. You build the script once, it runs unattended, and it is ready quickly. RPA is also useful as a complement to other tooling: you use document AI to extract data from a PDF, and RPA to enter that data into the right screen in your ERP. This combination is common in practice. The problem starts the moment the source file varies. A supplier updates their invoice layout, a new shipper sends CMR documents in a different format, a customer emails orders in a slightly different table. The RPA script fails, no one notices immediately, and somewhere in the chain the data is no longer correct.
Why does RPA break on unstructured documents?
RPA works on position or pattern: it looks for a value in a fixed location or via a fixed regular expression. The moment the layout changes, the script can no longer find the value. This is not a bug; it is a design choice. RPA is built for stability, not for variation. Documents such as incoming orders, CMR waybills, packing slips, or inspection photos are variable by nature. They come from dozens or hundreds of different senders, each with their own layout, abbreviations, and field arrangement. Every new format means, in an RPA approach, writing a new rule, testing it, and managing it. With a handful of fixed suppliers that is manageable. With an operation that has a broad supplier base, it quickly becomes a full-time maintenance task.
What are the concrete trade-offs of document AI compared to RPA?
Document AI solves the variation problem but comes with its own considerations. First: implementation time. An RPA script for a single stable process can be built quickly, sometimes in days. Document AI requires an initial setup: which fields do you want to extract, what rules apply for matching, what does the output look like. At dottle that goes live within two weeks, but you do need to plan that time. Second: transparency. Well-built document AI flags what it is not confident about and passes the decision to a person. RPA does not do this on its own: it either succeeds or fails, and when it fails you sometimes only find out after the damage is already done. Third: long-term maintenance burden. With document AI you add a new format as a new rule or extraction set, in a controlled way. With RPA you adjust the script and hope it does not affect another workflow. As the number of document sources grows, the balance clearly tips in favour of document AI.
When does a combination of RPA and document AI make sense?
The two are not mutually exclusive. The most common combination: document AI reads the incoming document and delivers structured data, while RPA or a direct API integration places that data into the target system. You play to the strengths of both: document AI on the unstructured input, RPA or an integration on the stable system action. This is also exactly how dottle works: the output goes via an integration to your ERP, TMS, WMS, or accounting package, eliminating manual re-entry without building a fragile end-to-end RPA script that has to read through the entire document. A combination makes less sense when the document already arrives fully structured. In that case document AI is overkill, and a direct integration or simple RPA script is sufficient.
When is document AI not the right fit?
Being honest means saying this too: document AI is not always the right choice. If you have one fixed supplier who always delivers the same structured format, building a lightweight integration or a simple script is faster and cheaper. If document volume is low, fewer than a few hundred documents per month, the payback period is long. And if the underlying process is not yet defined, meaning it is unclear exactly what needs to go into which field, then automation solves nothing: it just locks in the chaos faster. Automation only makes sense when you know what you want to automate.