When an accounting team processes an invoice by hand, two different problems are actually at play. The first is mechanical: reading data from one place and typing it into another system. The second requires judgment: where is the amount on a scanned document, what format is the supplier name in, is this email an order confirmation or a complaint. Classic RPA (robotic process automation) solves the first problem but stalls on the second — a rule-based robot expects the same information in the same place on screen every time. Change the format, add handwriting, or send free text, and the robot fails.
This is exactly where artificial intelligence steps in. Over the past few years, most RPA platforms have built document understanding and natural language processing directly into their tools; this combination is usually called intelligent automation or IDP (intelligent document processing). This piece looks at what that combination means in practice for a manufacturing SME, which processes it opens up, and where to start.
The difference between classic RPA and intelligent automation
Classic RPA works like a literal assistant: tell it “open this screen, read this field, write it into that system,” and it follows the instruction exactly. It runs smoothly as long as the input always arrives in the same layout — a fixed-format order form, a standard spreadsheet report.
Intelligent automation adds an understanding layer in front of the robot. This layer can locate an amount on a scanned invoice regardless of which cell it sits in, classify the subject of an email, or extract specific clauses from a contract. The robot still handles the repetitive work; the difference is that it can now cope with input that isn’t standardized. In practice, this means stacking two layers:
- The RPA layer: moving data between systems, filling forms, clicking through steps — the mechanical work.
- The AI layer: document reading (OCR plus understanding), text classification, field extraction, simple decision logic — the work that requires interpretation.
Once these two layers work together, processes previously dismissed as “not fit for automation” come back onto the list.
Which processes are now open to intelligent automation?
The most common examples in SMEs:
- Reading free-format invoices and receipts: automatically capturing invoices that each supplier sends in its own layout and posting them into accounting or ERP.
- Classifying and routing incoming email: sorting orders, complaints, and quote requests by content and sending each to the right team.
- Summarizing contracts and documents: pulling out critical fields such as delivery dates or payment terms from a long supply contract.
- Pre-screening customer request forms: tagging free-text requests by subject and priority before they enter the workflow.
- Digitizing quality and maintenance records: reading handwritten field forms or photos and entering them into the system.
What these have in common: the input is still repetitive work, but its format is now variable — precisely where classic RPA used to stall.
Where to start: a three-step framework
Sequencing matters before jumping into intelligent automation. Picking the most complex process first tends to stall the whole project within the first month.
- Start with a high-volume, low-risk process. Invoice reading — frequent, and easy to correct when it goes wrong — makes a good first pilot. Don’t begin with a process that goes straight to a customer and is hard to reverse.
- Measure accuracy from day one and keep watching it. Intelligent automation tools don’t read with perfect accuracy; what matters is that the robot hands off any case it isn’t confident about to a person (an exception queue). Projects that don’t track this rate steadily lose trust.
- Avoid overlapping with your ERP’s own automation. If a modern ERP already defines approval flows or automatic stock deductions, rebuilding the same logic in RPA just adds an unnecessary layer. On the digital transition side, the first decision is which part of a process belongs inside the system and which part needs a bridge between systems.
Where does the human stay in the loop?
Intelligent automation is not a project to remove people from the process; it’s a project that clarifies exactly where a person’s judgment is needed. The robot processes cases it reads with high confidence directly and routes low-confidence cases to a person. This split is what keeps the system both fast and reliable. Skip it, and one of two failure modes shows up: either the robot asks a person about everything (defeating the purpose of automation), or it asks about nothing (letting errors accumulate silently inside the system).
That’s why building an intelligent automation project means setting up more than the technical integration — it means setting up an exception-handling process: who reviews cases below which confidence threshold, and when.
Data protection considerations
Invoices, contracts, and customer emails can contain personal data. Before going live, a few questions need clear answers:
- Where does the document-understanding layer run, and in which country is the data processed?
- Does the vendor contract clearly define data processing terms under applicable data protection rules?
- Who has access to cases that land in the exception queue, and is that access logged?
Going live without answering these questions trades speed for compliance risk.
Common mistakes
A handful of mistakes show up repeatedly in intelligent automation projects:
- Choosing the tool before the process. “Let’s buy an RPA tool, then figure out where to apply it” runs the sequence backwards. The process and its volume should be clear first; the tool comes after.
- Scaling the pilot before measuring it. Moving on to a second or third process before tracking accuracy, exception volume, and time saved on the first one just carries problems forward at a larger scale.
- Leaving the exception queue unowned. Cases the robot isn’t confident about land somewhere — if nobody watches that queue, errors quietly build up in a corner of the system nobody checks.
- Leaving out the process owner. The person who understands a process best is usually not the automation team but the person who does the job daily; without their input early on, the robot gets built on the wrong assumptions.
What these mistakes share is treating automation as a software project rather than a process change project. Building the robot is a technical task; deciding which work gets checked, when, and by whom is an organizational task — and that second part is usually where the real difficulty lies.
Decision framework: what fits which scale?
| Scale / situation | Suggested approach |
|---|---|
| A small number of standard-format documents | Classic RPA may be enough; an AI layer may not be needed |
| A high volume of variable-format documents (invoices, email) | Intelligent automation (RPA + document understanding) makes sense |
| A modern ERP with its own rule engine already in place | Evaluate in-ERP automation first, fit RPA into the remaining gaps |
| A process handling significant personal data | Settle data processing location and access controls before the automation design |
İkiz Eksen’s approach
İkiz Eksen works out, together with a team, which part of a process belongs to the ERP’s own rules, which part to RPA, and which part to AI-assisted document understanding. The goal isn’t to add more robots; it’s to free up the team’s time from repetitive work so it can go toward higher-value tasks. Take a look at our solutions or get in touch to talk through your process.
Frequently Asked Questions
What’s the core difference between RPA and intelligent automation?
Classic RPA automates rule-based work where the input always arrives in the same layout. Intelligent automation adds AI capabilities such as document understanding and text classification on top, so it can also handle input with variable formats.
Does a small business need intelligent automation, or is classic RPA enough?
If your documents usually arrive in a fixed template, classic RPA may be sufficient. If you’re processing invoices in different formats from different suppliers, or handling free-text email, the AI layer makes a meaningful difference.
Is intelligent automation ever wrong?
Yes. Accuracy depends on document quality and process complexity. What matters is that the robot automatically routes any case it isn’t confident about to a person — going live without that exception-handling mechanism is risky.
If our ERP already has automation, do we still need RPA?
Usually both are used together, but with different roles: work that lives inside the ERP is handled by the system’s own rules; RPA and intelligent automation step in for work that needs a bridge between systems or sits outside the ERP.
Can intelligent automation be set up in compliance with data protection rules when documents contain personal data?
Yes, but the data processing location, the vendor contract, and access/logging controls need to be settled at the design stage. Skipping these steps creates compliance risk; if you’re unsure, confirm with your data protection advisor.