AI Automation Readiness: A Self-Assessment Checklist

"Are we ready for AI?" is the wrong question, because the answer is always "for some things". The useful questions are which process is ready, what is missing for the next one, and what to do first. This is the checklist behind the PTAS AI Automation Benchmark. Work through it honestly for one process and you will have answers to all three.

What readiness means, and what it does not

Readiness is not a technology score. A team with the newest ERP and no documented exceptions is less ready than a team on Tally with a clean vendor master and a written approval policy. Readiness measures how much of a process can be described, fed, connected and governed well enough for software to run it, and for people to trust what it did.

It is also local. A company is not ready; a process is. Payables may be ready while customer onboarding is not. Score the process you intend to automate first and leave the others for later. A single company-wide number flatters the strong areas and hides the one that will stall the project.

How to use this checklist

Seven dimensions, weighted the way the benchmark weights them: Process 25, Documents 20, Data 15, Integration 15, Workflow 10, AI 10, Governance 5. The weights say where readiness is usually won or lost: in the process itself and in the documents that feed it, far more than in how much AI a team has used before.

Answer each question with the people who do the work, not the people who own it. The owner knows the policy; the clerk knows the exceptions. Then read what each answer means. A low score in a dimension is not a reason to wait. It is the first piece of work, and it is usually cheaper than it looks.

Process (25 points)

• Can you write the process down as steps with inputs and outputs, and does the written version match what the team does on an ordinary Tuesday?
• Do you know the volume: documents or transactions per month, and the peaks?
• Do you know the exception rate and the top five causes, from data rather than from memory?
• Is there one owner who can change the process?
• Which steps are rules (if this, then that) and which need judgement?

If the process cannot be written down, that is the first project, and it is a week of working sessions, not a purchase. If the exception causes are unknown, count them for a month before choosing anything; the causes decide whether you have a document problem, a data problem or a policy problem, and each has a different first step. If nobody can change the process, automation will stall at the first exception that needs a new rule. The Business Process Automation page describes how we scope a process, and the exception count is the single most useful thing you can bring to that conversation.

Documents (20 points)

• What arrives: invoices, purchase orders, GRNs, statements, KYC packs, contracts? From how many sources, in how many layouts?
• What share is digital PDF, and what share is scanned or photographed?
• Which fields does the downstream step actually need, and are they printed on the document?
• How much is typed by hand today, and by whom?

Layout variety and scanned input are not blockers; reading them is what document AI is for. They do decide the review design and the pilot set. If a field you need is not on the document (a cost centre, a project code), the automation needs a lookup rather than better reading. If hand-keying is the main labour, document automation is almost always the first and highest-value project. Intelligent Document Processing explains the capability, DocPro is the product, and the document test will read one of yours now.

Data (15 points)

• Is the vendor master clean: one record per legal entity, verified tax IDs and bank details, no duplicates?
• Are reference data (chart of accounts, cost centres, tax rate masters, approval bands) kept in one place with an owner?
• Can you export a month of transaction history in a structured form without asking IT for a favour?
• Is the same thing named the same way in every system?

Automation inherits the data it is given. A vendor master full of duplicates makes matching unreliable and vendor checks impossible; a stale rate master makes tax validation wrong with great confidence. If the answer to the first question is no, clean the master before or alongside the first project. It is tedious, and it is the highest-return data work in finance. Vendor Management Automation covers how a cleaned master is kept clean afterwards.

Integration (15 points)

• Which systems hold the process: ERP, procurement, bank portal, email, spreadsheets?
• For each, what access exists: a documented API, a file import and export, a database, or only a login screen?
• Who owns the integration decision, and how long does it take to get a test environment?
• Has any of these systems been integrated by a third party before?

An ERP with a documented API or a file interface is ready. One whose only door is the screen pushes you towards file-based or custom integration, which is workable but has to be scoped on day one, not discovered in week six. We distinguish native, API, file and custom integration, and any named system in a plan is an example until its method is confirmed during assessment. The slow path to a test environment is the most common cause of a late project, ahead of any technical difficulty. See Integrations for the methods and the systems, and FinSuite Integrations for what moves in a finance deployment.

Workflow (10 points)

• Are approval thresholds written down, by value and by category, with delegation rules?
• Does the workflow leave a trail: who approved, when, on what basis?
• Are there agreed service expectations for each step?
• Does the workflow stop for the right reasons, and can anyone see what is stopped?

If you cannot draw the ladder an invoice climbs, like the one above, the workflow lives in people's heads, and automation will expose every disagreement about it at once. Write the thresholds down first; that alone usually removes a share of the delays before any software is involved. A workflow that already leaves a trail is ready for a system that keeps one. Workflow Orchestration covers the design.

AI (10 points)

• Has the team used any AI or automation tool in production, and what happened?
• Is there a view on what AI should and should not decide?
• Who would review what the AI holds, and do they have the time?
• Are expectations about accuracy and timelines realistic?

This dimension is deliberately light. Prior AI experience helps, but it is not the gate. What matters is whether the team has thought about review and control. If nobody has time to review, start with a narrower scope. If the expectation is that every field is right from day one, reset it before the pilot: field-level confidence, validation and review are how the system earns trust, and the first weeks are for measuring. The human-in-the-loop guide is the design to read before answering the third question.

Governance (5 points)

• Who owns the risk if the automation is wrong?
• Are data handling requirements clear: what may leave the premises, what is retained, who may see what?
• Is there an audit expectation the automation has to meet?
• Who approves changes to rules and thresholds once it is live?

Five points is the weight, but this is the dimension that stops a live project fastest. Data handling decides the deployment (cloud, private cloud, or on-premise where supported). Audit expectations decide what the trail must contain. Rule-change governance decides whether the control stays a control after the consultants leave. AI Security and Governance describes the model we apply.

Reading your result

The benchmark groups scores into four bands. The band matters less than the first piece of work it points to.

• Emerging. The process is not yet written down, or the exceptions are unknown. First work: document the process and count exceptions for a month. Then choose one narrow document flow.
• Developing. The process is known, but data or integration is weak. First work: clean the master that matters and settle the integration method. A pilot can run alongside.
• Automation Ready. Process, documents and data are in shape; workflow and governance need writing down. First work: thresholds and review design, then a pilot on live volume.
• Advanced. Most dimensions answered well. First work: pick the highest-volume process and start, with measurement from the first day.

The score is a structured conversation, not a certificate, and it has not been validated against anyone else's outcomes. Treat it as the agenda for the first meeting.

How to test this on your own process

Half a day, one process, the people who do it.

1. Write the process in ten steps or fewer, with the people who run it in the room.
2. For one week, count every item that needed a person for a reason other than approval, and write the reason down each time.
3. Pull twenty documents from the process. Count how many are scanned, how many layouts there are, and whether every field you need is on them.
4. Open the vendor or customer master and count the duplicates. Do not estimate; count.
5. List every system the process touches and the access you have to each.
6. Draw the approval ladder from policy, then check it against three recent approvals.

What you will have is a defensible answer to where to start, and a list of what to fix before or alongside it. If the exercise shows a finance process, the finance workflow assessment goes deeper on matching, approvals and tax; if it shows a document flow, Document Workflow Automation describes what the first project usually looks like.

From checklist to score

For payables, the finance workflow assessment asks these questions online, scores them with the weights above, and returns your band with the two next steps we would take. It takes about seven minutes, and it is the same method described on the benchmark page. For any other process, book a call and bring the exception count. The other guides cover the individual processes in the depth a first project needs.