Automating Documents and Forms Without a Developer: What Power Platform Can and Cannot Do for You

To automate customer forms, invoices and handwritten notes so they are searchable and auditable, split the job in two. Information that does not exist yet should be captured at source: a Microsoft Forms or Power Apps form writes it into SharePoint or Dataverse with who and when recorded, on tools most organisations already license. Documents that already exist need extraction. AI Builder document processing reads consistent printed layouts such as supplier invoices reasonably well and handwriting unreliably, so when the output feeds an audit a person must verify each extracted value before it becomes the record. Build capture first, pilot extraction on your own documents, and something auditable can exist within weeks.

Why are capturing new forms and extracting existing documents two different problems?

Because the hard part is different. When a form has not been filled in yet, you control how the information arrives: you can make a field required, restrict it to a list, validate a date and record the person submitting it. Nothing needs to be read or guessed, so the data is right at the moment it is created.

When the document already exists, as a stack of paper customer forms, emailed supplier invoices or a notebook of handwritten site notes, you control nothing about how it was written. Software has to read it and propose values, and some of those values will be wrong. That makes extraction a quality control problem as much as an automation one.

Most organisations facing an audit have both, and the mistake is to treat everything as extraction: scanning new paper forms every week and paying to read them, when the form could have been replaced. The first question for each document type is simply whether it will keep arriving. If it will, replace it at source. If it is historic or comes from outside, extract it.

What does the capture, store and record pattern look like on tools you already license?

For information your own staff or customers provide, the low cost pattern has three parts, and in many Microsoft 365 tenants the standard version needs nothing new. Check current Microsoft licensing documentation for your plans, because what counts as standard or premium changes.

• Capture. A Microsoft Forms form for simple customer or internal submissions, or a Power Apps canvas app where people need scanning, photos, offline working or lookups against existing records.
• Store. A SharePoint list or library with version history on for straightforward registers, or Dataverse where records relate to each other, need row level security or feed Dynamics 365. Dataverse usually needs premium licensing for the people who use it.
• Record. A Power Automate cloud flow that runs on each submission, writes the structured record, files any attachment with a consistent name, stamps the submitter and the server time, and notifies whoever acts on it.

Two design choices make it auditable rather than just digital. Submitters should not be able to edit or delete a record after it is filed; corrections are new entries that reference the original. And every person signs in as themselves, because a shared login makes every record unattributable. Designing the capture app itself for frontline conditions, including scanning over typing, validation at entry and offline behaviour, is covered in how Power Apps replaces paper forms on the shop floor, so it is not repeated here.

What does AI Builder document processing do well?

AI Builder is the part of Power Platform that reads documents inside a Power Automate flow. It offers prebuilt models for common document types, such as invoices and receipts, and a custom document processing model that you train on examples of your own layouts. The flow receives the extracted fields, table rows and a confidence score for each value, and can write them wherever the capture pattern above would.

It tends to do well when the documents are:

• Printed or generated by a system rather than written by hand.
• Consistent in layout, such as invoices from the same supplier or a form your organisation designed.
• Clean scans or original PDFs at a readable resolution, the right way up, one document per file.
• Asking for labelled fields, such as an invoice number, a date, a total or a checkbox with a clear label.

Capabilities, supported languages, model types and how AI Builder is licensed or metered have all changed over time and continue to, so confirm the current position in Microsoft documentation before designing around a specific model or volume. The honest way to know how well it reads your documents is a pilot on a sample of your own, not a vendor demonstration on clean examples.

Where does document processing struggle, especially with handwriting?

Handwriting is the weak point. Text recognition can read some handwriting, but results vary widely with the writer, the pen, the language and whether the writing stays inside the boxes. A custom model trained on printed forms may extract a handwritten field inconsistently or not at all. Treat handwritten values as candidates for a person to confirm, not as data.

• Handwritten notes with no fixed structure, where there is no field for the model to find.
• Poor scans: faint carbon copies, phone photos at an angle, shadows, stamps and signatures across printed text.
• Many layouts in one pile, such as invoices from hundreds of suppliers with no dominant format, which widens the range of errors.
• Values that look similar and matter, such as 1 and 7, 5 and S, or day and month order in dates.
• Tables that run across pages, merged cells and totals that have to reconcile with line items.
• Meaning rather than text: the model can read that a box says "approved", not whether the right person approved it.

A confidence score helps route work, but a high score is not proof a value is correct. A misread digit on a total can arrive with a confident score. That is the reason for the next section.

Why is a human verification step mandatory when the output feeds an audit trail?

Because an auditor asks who confirmed that a number is right, and "the model read it" is not an answer they can accept. Extraction produces a proposal. The record becomes evidence only once a named person has checked it against the source document.

The pattern that holds up:

• Keep the original. The scanned file or PDF is stored unchanged, read only, next to the record it produced, so anyone can compare the two later.
• Stage the extracted values. The flow writes what AI Builder proposed into a staging list or table, with the confidence per field, never straight into the register the audit relies on.
• Review every record, not only the low confidence ones, where the output is audit evidence. Show the reviewer the document beside the proposed values, and make them confirm or correct each field.
• Record the review. Store who verified the record, when, and which fields they changed from the proposed value. Those corrections are also your best measure of how well extraction is really working.
• Promote only verified records into the register, and lock them there.

Confidence thresholds can still earn their keep outside the audit path, for example deciding which documents to review first. Reducing the review to a sample is a decision for whoever owns the audit, made on measured correction rates from your own documents, not a default. Where the register lives in Dynamics 365, how auditing and field history behave there is covered in our guide to Dynamics 365 audit trail compliance.

How do you make a backlog of historic paper searchable without extracting every field?

Not every old document needs to become structured data. For many audits, what matters is that a document can be found and shown to be the original. Scan the backlog to PDF with text recognition applied so its content is searchable, store the files in a SharePoint library with versioning and retention settings agreed with whoever owns compliance, and tag each file with a handful of index fields a person can fill quickly, such as customer, date, document type and reference.

Then extract fields only where a process or a report genuinely needs them, such as invoice totals that must reconcile, and send those through the verification pattern above. Reading every field of every historic form costs review time on data nobody will query. When the audit asks for figures rather than documents, building reporting an auditor will accept from what you have is set out in standing up trusted reporting fast.

What phased plan produces something auditable within weeks?

Timings depend on volumes, how many document types you have and how quickly owners make decisions, so treat these as phases rather than a promise.

1. Map the documents. List every form and document type, where it comes from, how many arrive, whether it will keep arriving, and what the audit needs from it: the document itself, specific fields, or both.
2. Replace the recurring internal forms at source. Build the capture, store and record pattern for the highest volume form first, with locked records and individual sign in, and switch it on. This is usually the quickest auditable result.
3. Pilot extraction on a real sample. Take a representative set of each external document type, run it through the prebuilt or custom model, and have a person verify every field, recording corrections. Decide per document type from those numbers whether extraction saves time at all.
4. Put verified extraction into production for the types that passed, with originals retained, staging, review and promotion.
5. Make the historic backlog searchable with scanning, text recognition and index fields, extracting only what a process needs.
6. Hand over the operation: a named owner for the review queue, alerts on failed flows, and a periodic check that registers, originals and review records still match.

What can you build without a developer, and when do you need one?

A capable Microsoft 365 administrator or business analyst can build a Microsoft Forms to SharePoint flow, a simple Power Apps form and a prebuilt model on a consistent document type. That is a genuine first step and often enough for one process.

Bring in experienced help when the output is audit evidence and the controls have to hold, when documents come in many layouts or handwriting matters, when records must land in Dataverse or Dynamics 365 with security and validation that apply however the data arrives, or when volumes need error handling, retries and monitoring that someone has to own. That is the flow, AI Builder and document processing work we deliver through our Power Automate consulting service, directly or white-label for Microsoft partners. Where the forms and records belong in a system outside the Microsoft estate and licensing is the obstacle, a custom-built CRM on React, Node.js, PostgreSQL or .NET is the alternative we build. We do not implement ERP or finance systems, so invoice extraction here stops at a verified record handed to the system that owns accounts payable.