An intelligent document processing rollout in a large enterprise runs in six stages: discovery, sample collection, model and rules set-up, parallel run, exception handling and scale. How long each takes depends on document variety, system access, rule agreement, review capacity and the number of business units, so no honest single duration exists for every company.
"How long will it take?" is the first question a COO or CIO asks, and the most common reply, a number of months, is usually a guess dressed as a plan. This guide gives the stages, what must be true to leave each one, and the factors that stretch or shorten it, so you can ask a supplier for a schedule that is built from your facts. For how the extraction pipeline itself works, see our intelligent document processing guide; for how to score the results, see IDP accuracy and straight-through processing. If you want a team to build the pipeline, start with AI document processing.
Key takeaways
- A large-enterprise rollout is a sequence of stages with exit criteria, not one project with one end date.
- Duration is set by people and access more than by the model: sample documents, system credentials, rule sign-off and reviewer time.
- Start with one document type in one business unit, prove it, then widen. Do not launch every entity at once.
- The parallel run is the stage that gives you evidence. Do not skip it to save time.
- Exception handling is a permanent operating process with an owner, not a phase that ends.
- Ask any supplier for a schedule with assumptions written down, and which assumptions are yours to meet.
What are the stages of an IDP rollout in a large enterprise?
The six stages are discovery, sample collection, model and rules set-up, parallel run, exception handling and scale. Each has an entry condition, an output and an exit test. Moving on before the exit test is met is the most common cause of a rollout that stalls in the middle.
| Stage | Main work | Exit test | Main owner |
|---|
| 1. Discovery | Inventory document types, channels, volumes, systems and approval steps; pick the first document type | A written scope with named owners and a success measure | Process owner and project lead |
| 2. Sample collection | Gather real documents across suppliers or senders; label correct values | A labelled development set and a held-back test set | Operations and finance staff |
| 3. Model and rules set-up | Configure extraction, validation rules, thresholds, the review screen and the ERP connection | Results on the development set meet the agreed targets | Delivery team with finance |
| 4. Parallel run | Process live documents through the new system while staff keep working the old way, and compare | Accuracy and false acceptance on live data meet the test-set results | Process owner |
| 5. Exception handling | Staff work the review queue; reasons are tracked; rules are tuned | Queue age, correction rate and error audits are within targets | Operations lead |
| 6. Scale | Add entities, document types, languages and channels, one at a time | Each addition repeats stages 2 to 5 at smaller scale | Programme lead |
Stage 1: Discovery
Discovery decides what you are building and what you are leaving out. It produces an inventory of document types (supplier invoices, credit notes, forms, contracts), where each arrives (inbox, portal, scan, fax, courier), how many a month, which systems consume the data, and who approves what afterwards.
The discovery output that saves most time later is a success measure written before any build: the cost of a wrong value, the target for straight-through processing, and the review capacity you can staff. Choose the first document type by value and tractability: high volume, repetitive handling, a clear destination system, and an owner who will sign off.
What stretches it: many business units each insisting on their own process, unclear ownership of the data, and documents arriving through channels nobody has counted.
Stage 2: Sample collection
Sample collection gives you the evidence base. Collect real documents across senders, layouts, languages, scan quality and months, include the ugly ones, and have staff label the correct values. A sample that contains only clean documents produces a plan that fails in the parallel run.
What stretches it, and what you control:
- Getting documents out. Legal, privacy and security reviews may be needed before documents leave their system, especially when they hold bank details, personal data or health information. Start these approvals during discovery.
- Labelling capacity. The people who know what the right answer is are the same people doing the daily work.
- Variety. Hundreds of senders with different layouts need a larger and more carefully stratified sample than a few dozen.
- Document families. Each additional type, such as credit notes or statements, needs its own labelled examples.
Stage 3: Model and rules set-up
In this stage the delivery team configures extraction for the document types, writes validation rules with finance or operations, sets thresholds per field, builds the review screen and connects to the target system. The rule work involves the most meetings: tolerances, tax codes, who owns a rejected document, what a duplicate means.
What stretches it:
- Number of integrations. Each ERP, workflow tool or case system is an interface to build and test.
- Master data quality. Duplicate vendors and missing tax numbers must be fixed or the rules misfire.
- Rule agreement. Policies that differ by entity or country need to be reconciled or built as separate configurations.
- Security and architecture reviews inside your organisation.
Does sandbox access make an IDP rollout faster?
Yes, but only for the part it covers. Access to a sandbox or test environment of your ERP or workflow system, with test credentials and sample reference data, removes the wait before the integration can be built and tested. It does not shorten sample collection, rule agreement, the parallel run or reviewer training, which usually take more calendar time.
If you already have sandbox access, expect it to save the wait for a test environment and nothing else. Ask the supplier to list what else must be in place: sample documents, labelled values, rule decisions, production credentials, a named reviewer team, and security approval for the production environment. Anything on that list not yet ready sets the date.
Stage 4: Parallel run
In a parallel run the new system processes live documents while staff continue the existing process. You compare the two sets of results, document by document, and measure accuracy, false acceptance and exception causes on current data rather than on the test set.
This is also called shadow mode. It is the stage where surprises surface: a supplier changes a template, a seasonal document type appears, a rule that looked right on the sample raises hundreds of needless exceptions. Do not shorten it because the test-set results were good. A good rule is that the parallel run ends when results over a defined period meet the targets you set in discovery, and not on a calendar date.
Move from parallel to live in steps: first post drafts for review, then allow straight-through only for the fields and senders where the evidence supports it, as the human-in-the-loop design guide describes for AI actions in general.
Stage 5: Exception handling
Exception handling is where the system meets your organisation every day. Documents that fail validation or fall below thresholds go to a queue with a named reason. Someone must own the queue, work it within an agreed turnaround, and feed corrections back.
Plan for it as an operating process:
- A named owner and a deputy, with cover for leave and month-end peaks
- Reason codes, such as "vendor not found", "quantity exceeds receipt", "bank details differ"
- A target for queue age, and escalation when it is missed
- A weekly review of the top exception reasons, deciding for each whether to fix the rule, the master data, the supplier's invoice or the extraction
- Corrections stored as new labelled data for the next tuning round
What stretches it: understaffed review, rules that are too strict, and exceptions that need an answer from another department.
Stage 6: Scale
Scale adds entities, countries, languages, document types and channels one at a time, each repeating a smaller version of stages 2 to 5. The first rollout carries the platform work; later additions mostly carry sample collection, rule differences and training.
| Scale dimension | Added work per step | Common surprise |
|---|
| New entity in the same ERP | Entity master data, local tax codes, local approvers | Different chart of accounts or tolerances |
| New country or language | Labelled samples in that script, local tax and invoice rules | Number and date formats, mandatory legal text |
| New document type | New fields, validation rules, destination | Different owner and different cost of error |
| New channel (portal, EDI, scan) | Capture and de-duplication | The same invoice arriving by two routes |
| Another ERP | A second integration | Different identifiers for the same vendor |
How do document types change the rollout?
The stages stay the same, but the weight moves. Lending and equipment-finance files need heavy field and rule work, healthcare administration forms need privacy and security approval first, and freight invoices depend on validating charges against rate agreements and delivery documents. Each family needs its own samples, rules and owner. In more detail:
- Equipment-finance and lending documents (applications, schedules, insurance certificates, title documents) carry many fields per document, and field definitions often depend on the product, so rule and sample work is heavy.
- Healthcare administration forms such as prior authorization requests mix typed forms, faxes and clinical attachments, and contain health information. Privacy and security review comes first, and confirmation of legal obligations stays with your compliance team.
- Freight and logistics invoices have line charges and accessorials that must be matched to rate agreements and delivery documents; the validation rules matter more than the extraction.
Worked example (illustrative)
A group with five operating companies plans to read supplier invoices. It chooses the largest company's PO-backed invoices as wave one. Discovery counts 14,000 invoices a month there and finds that 20 percent arrive by post and are scanned.
Wave one collects 600 labelled invoices, writes eleven validation rules with the finance controller, and connects to the ERP's test environment. The parallel run covers a full month-end, the busiest and least typical period, and finds that credit notes are being treated as invoices; a classification rule is added before go-live. Review staffing is sized from the measured exception rate, not from the vendor's claim. Waves two to five then reuse the pipeline and add each company's tax codes, approvers and layouts. All numbers are invented to show the sequence; real volumes decide real dates.
What should be ready before kickoff?
Before kickoff you need named owners, privacy-approved samples, test-system access, protected reviewer time, a master data owner and written success measures. Missing items rarely stop the build; they stop the evidence, which stalls the decision to go live, so check each one before a date is promised.
| Item | Why it matters |
|---|
| Executive owner and day-to-day process owner | Decisions on rules and exceptions need someone with authority |
| Access to sample documents, with privacy approval | Stage 2 cannot start without it |
| Sandbox and later production access to target systems | Integration cannot be tested without it |
| Named reviewers with protected time | The exception queue is staffed from day one of the parallel run |
| Master data owner | Vendor and item data will need cleaning |
| Agreed success measures | Without them, "done" is a matter of opinion |
When this is the wrong approach
A staged enterprise rollout is more process than you need if documents are few, if suppliers can send structured e-invoices or EDI, or if the real bottleneck is approval, not data entry; in that case look at workflow automation first. Also pause if you cannot name reviewers: an unstaffed exception queue turns automation into a backlog.
Glossary: parallel run (shadow mode), new and old processes run together and are compared; exit test, the evidence required to leave a stage; wave, one entity, document type or channel added in sequence.
How Timeline Digital approaches an IDP rollout
Timeline Digital delivers remotely from Islamabad, where it was founded in 2013. For a rollout like this the schedule is set from your requirements in the Plan step, not quoted as a fixed number. A free pilot of 2 to 3 key modules comes first, tested by your team before the final agreement, and source code transfers to you on full payment. To discuss a staged rollout, Discuss Your Project.