Content Understanding & Document AI - Simply Explained

Your team might have plenty of automation, yet a shared inbox still fills with invoices, receipts, forms, contracts and PDFs that somebody has to open and read. Each document looks harmless on its own, but manual copying turns that pile into slow work, missed details and errors that show up later. You might think the challenge is scanning paper, it isn't. The real tension here is turning messy content into business data your process can trust. Welcome to the M365 FM podcast, where we explore the people, ideas and technologies shaping the future of work. We're looking at content understanding, OCR, AI builder and power platform. So when does the document stop being an attachment and become usable data? Why documents break automation? Picture three invoices arriving before lunch. The first is a clean PDF from a supplier you've worked with for years. The second is a phone photo, slightly crooked, with a shadow across the total. The third comes from a new supplier and the invoice number sits in a completely different spot, to a person they're all invoices. To a basic automation they can look like three unrelated problems. That's because most business documents aren't neat database records. A database gives every field a fixed home. Supply a name here, total there, due date in this column. A document gives you words, tables, logos, stamps, notes and blank space arranged for a human reader. It may look organized, but the computer doesn't automatically know which parts matter. Some documents are unstructured. Think of a contract and email attachment, or a letter where the useful information lives inside normal sentences. Examples are semi-structured and invoice usually contains familiar details, but every supplier lays those details out differently. The fields exist, just not in the same place every time. Now think about the worker person does without noticing it. You open the file, spot the supplier name, find the invoice number, check the date, read the total, compare it to a purchase order, enter it into a system, then send it to somebody if something doesn't match. That isn't just reading, it's a chain of small decisions, rules-based automation struggles because it expects consistency. You can tell it, read the text beside this label and it may work for one invoice template. With the supplier changes, invoice number, to reference. A scant page moves the label. A photo blurs one digit. The document arrives in another language. Suddenly, the rule doesn't know where to look, even though a person would understand the intent in seconds. This is why teams often build a flow that works beautifully in a demo, then watch it fail when real documents arrive. Real documents contain bad scans, unexpected layouts, missing fields, handwritten notes and people who don't follow the template you hoped they would. OCR helps, but only up to a point, OCR means optical character recognition. Put simply, it reads the characters it can see in an image or document. It can turn a picture of INV10482 into text, that's useful. But OCR doesn't always know what that text means. A page may contain several long numbers, one might be an invoice number, another a purchase order number, another bank account, and another a phone number. Reading the characters doesn't answer the business question, which one should enter your invoice system. The same problem appears with dates and amounts. OCR may capture 0.4, 0.526, but is that April 5th or May 4th? It may read 1,000,000,000,000, but does that mean the invoice total, align item, tax or a previous balance? Context decides the answer. So if reading text isn't enough, the process needs a layer that can look at the document's purpose and pull out the information that the business actually needs. Content understanding simply explained. Microsoft content understanding is the layer that takes a file, people can read, and returns information a business process can use. You give it content, tell it what matters, and it helps turn that content into structured results. Instead of leaving it trapped inside an attachment, think of structured information as a clean answer with named boxes. Rather than handing your process a whole invoice and asking it to figure things out later, you can receive a supplier name, invoice date, invoice number, total, and the items listed on the invoice. Each result has a label, so the next system knows what it received. The flow starts with the content itself. That could be a document, an image, or another, supported type of business content where you need to pull out information. Next, you describe the information you want back. Then content understanding examines the content, extracts the fields you asked for, and returns those results in a format software can work with. That description step changes the conversation. You aren't asking AI to read every word and give you a long explanation. You're giving it a job. Find the supplier, identify the date, pull the total, classify the document, and return a clear answer. Take the invoice number. To a person an invoice number means the number that identifies this specific bill. You use it to find the record later, spot a duplicate, and link the invoice to the supplier that sent it. The meaning matters more than the shape of the text. A document might label it invoice no. Another might use bill reference. A third might place the number beside a logo with no label at all. The same page may include an order number, customer number, delivery note number, and tax registration number. Content understanding aims to identify the number that plays the invoice number role, not merely copy the first code that looks convincing. The distinction is why people often describe this as document AI rather than just text capture. The system works from the structure and context of the content along with the instructions and fields you define. It is trying to answer a business question, not produce a transcript. To keep those answers consistent, you define a schema. A schema sounds technical, but it simply means an agreed shape for the result. It tells the system, for this type of content, these are the answers we need, and this is what each answer should look like. For an invoice, your schema might include supplier name as text, invoice date as a date, invoice total as a number, and invoice number as text. You could add a document type field, because the same mailbox might receive credit notes, statements, purchase orders and invoices. If you need detail from the table, the schema can also describe line items such as description, quantity, unit price, and amount. The schema matters because it prevents a vague outcome. Without it, you might receive a broad explanation of the page that sounds useful, but doesn't fit anywhere. With it, you ask for data that a business process can check and use. You're moving from, tell me what this document contains to return these fields in this format, and you don't need every document to look identical for that idea to work. Content understanding can apply the same approach across business documents and images, where the job is to recognize useful information from content that wasn't built as a need record. A photo of a receipt and a supplier PDF can both contain details you need, even though they arrive in very different forms. Now, you might hear AI and picture a chatbot waiting for a question. That's a different job. A chatbot holds a conversation. It responds to prompts, explains concepts, and generates language. Content understanding focuses on the content you give it, and the fields you need returned from that content. You can think of it less like a colleague answering questions, and more like a specialist who receives a stack of files with a clear request attached. Find this, classify that, pull these details, return the results in the agreed shape. That focus gives you control. You define what matters for the use case, rather than hoping a general conversation produces a result that fits your process. The system can help with the hard part, finding meaning and varied content, while the schema keeps the output tied to the work you actually need done. But extracting a supplier name and a total only solves the first half of the problem. If those results sit inside a response that nobody checks and no system uses, the document still hasn't moved the business forward. The next question becomes much more practical, once content understanding returns the fields, what should happen next? That's where Power Platform turns extracted information into a real business process. The Power Platform connection, Power Platform gives those extracted fields somewhere to go and something useful to do. Power Automate acts as the process engine. It watches for an event, follows the steps you set, and passes the result to the right person or system. Imagine an invoice landing in a shared finance mailbox. A Power Automate flow can notice the new email, save the attachment, send that file to content understanding, and receive the fields it needs. From there, the flow checks the result against your business rules. You can store the record, root it for approval, or send a notification when somebody needs to look at it. The document starts the process, it doesn't end it. The same pattern works with a SharePoint folder. A supplier drops a PDF into a folder or a team scans receipts into a document library. Power Automate sees the new file and starts the flow without someone sorting attachments by hand. Content understanding reads the file. The flow takes the returned fields and decides what comes next. That decision can stay simple at first. If the invoice includes a purchase order number and the required fields come back cleanly, create a record and send it to finance. If the purchase order number is missing, send it to the person responsible for that supplier or request. The point isn't to automate every possible outcome on day one. The point is to send each document to a clear next step. Dataverse can hold the structured record behind that process, think of it as the business table for the work. Not just a folder full of files. Each document can have a record with its supplier, invoice number, date, total current status assigned owner, and the confidence returned for each field. You also keep a history. The record can show when the document arrived, when extraction ran, who reviewed it, what they corrected and where the process sent it next. When someone asks why an invoice sits in a queue, you don't need to hunt through an email chain. You can open the record and see the path it followed. That history matters once more than one person touches the process. Finance may only approval, procurement may need to check a purchase order. The person who uploaded the file may need an update. Dataverse gives the process one shared place to track ownership and status rather than letting each team keep its own version in email. Then Power Apps gives people a simple place to handle exceptions. Instead of receiving an attachment, a vague message, and a request to check this, the reviewer can open a screen build for that job. They see the original document next to the extracted fields. They can correct a supplier name, enter a missing reference, confirm the total, and send the item back into the flow. That makes human review part of the process rather than a detour around it. A few examples make the pattern easier to see. An invoice arrives, its fields pass the checks, and the flow roots it to finance for the next approval step. Another invoice arrives without a purchase order number, so the flow assigns it to a reviewer instead of letting it move forward with a gap. A contract enters a SharePoint library, content understanding pulls out an expiry date, and Power Automate creates a reminder for the contract owner before that date gets buried in a PDF. Different teams can use different rules, but the motion stays familiar, content arrives, information comes out, a decision follows, and the right person sees it when judgment is needed. No code means the hard part has disappeared, but no code only reduces how much software you write. It doesn't decide which fields matter, who owns an exception, what counts as an approval, or where the final record belongs. If the process is unclear before automation, it becomes unclear faster after automation, with more records moving through it. Good design starts with a plain question. After this document arrives, what decision needs to happen? Once you can answer that, the flow has a job. Content understanding supplies the information. Power Automate moves the work, data verse tracks it, power apps gives people a place to step in. The next part depends on how much the process should trust each result. Confidence scores help decide when a document can keep moving and when it needs a person to check it. Trust, confidence and human review. A confidence score helps the process judge how sure the AI is about a result. It isn't a promise that the value is correct. It's an estimate tied to a specific extraction, such as the supplier name, invoice date, or total based on what the system found in that document. That difference matters. A document can produce a strong result for the total because it's clearly printed, while the invoice number earns a weaker score because of folds, stamp, or blurry scan covers part of it. Treating the entire document as simply good or bad loses that detail. You need to judge the fields that carry the risk. For a low-risk internal request, you may let a high-confidence result move ahead with little friction. For an invoice total, the bar may be higher. For a payment instruction, a bank detail, or a date inside a legal agreement, you may require a person to confirm the field every time. Even when the score looks strong, the rule should follow the consequence of an error, not just the score. Picture an invoice total that returns with 98% confidence. That sounds reassuring, but the process still needs to ask whether the number makes sense. Does the total equal the line items plus tax? Does the supplier exist in your approved vendor list? Does the purchase order match? Has this supplier already sent an invoice with the same number and amount? AI reads the document. Validation checks test the result against the rest of your business. Some checks are simple. A date shouldn't sit in the future if your process only accepts completed work. A total shouldn't be negative unless the document is a credit note. A supplier name should match a known vendor, or at least trigger a review when it doesn't. Duplicate checks can stop the same invoice from entering the queue twice because someone forwarded the email or uploaded the PDF again. These controls don't compete with content understanding. They give its output a safety net. The extraction identifies a likely answer, then your rules decide whether that answer fits the business conditions around it. That's how you turn a useful AI response into a process people can rely on. Governance belongs in that same conversation, even though the word can sound like a policy meeting nobody wants to attend. In practical terms, governance answers a few plain questions. Who can create or change a model? Who can open the documents and extract it fields? Where does that content live? Who approves a change before it affects finance, HR or legal work? Those answers protect both the data and the people using it. If anyone can alter the extraction rules without review, a small change can quietly send documents down the wrong path. If access is too broad, private employee or customer information can land in the wrong hands. If nobody owns the process, error sit in a queue, while every team assumes someone else will fix them. Don't treat extracted data as automatically correct just because it arrived in a clean field. Clean formatting can create false confidence. A wrong total in a payment process, a wrong date in a contract or a wrong name in a compliance record can still cause a real problem, even if the automation completed every step exactly as designed. The safest first use case usually isn't the biggest pile of documents waiting in a shared mailbox. It's the document type with one clear decision, a known owner and a review path when the answer looks uncertain. Start there because a pilot with unclear rules doesn't stay small for long. It becomes technical debt. Only now the confusion runs automatically. Choosing a first use case that works. Start narrower than you think you need to. Pick one document type that arrives often enough to create annoying manual work, follows a broadly familiar pattern and leads to one clear business outcome. One voice intake can work well when the goal is to capture fields and root the item into an existing finance process. An employee onboarding form can work when the goal is to create a task list and make sure nothing gets missed. Claims, internal request forms and contract expiry dates can also work because each document can trigger a defined next action. The document isn't the project. The decision after the document is the project. Before anyone opens power automate or starts defining a schema, map the current path in plain language. What starts the process? Which fields does someone look for? What decision follows? What happens when information is missing or unclear? Where should the record end up? And who owns the item at each point? Write those answers down. If the team can't agree on them in a short conversation, AI won't solve the gap. It will just move the uncertainty from an inbox into a flow. For example, a simple contract use case might start when someone uploads assigned agreement. The process needs the supplier name, contract and date and contract owner. If the date is clear, create a reminder before the agreement expires. If the owner can't be identified, assign the document to a contract's coordinator. The final destination might be a dataverse record linked to the original file. Every step has a reason and every exception has a person. That kind of clarity creates a much better first build than a goal like let's use AI on all our documents. All documents means invoices, letters, scans, statements, contracts, handwritten forms and whatever arrives next Tuesday. Each type asks different questions and creates different risks. You don't learn faster by mixing all of them together. You just lose sight of why a result failed. Unclear ownership causes the same problem. A review queue without a named team becomes a parking lot. It's entered nobody acts and uses stop trusting the system. A process without a review path has the opposite failure. It forces uncertain information forward because there's nowhere else for it to go. Measure success through the work people no longer need to do. Our staff typing fewer fields by hand are documents reaching the right owner sooner, a few are files getting lost in inboxes, our records cleaner when someone needs to search report or audit them later. Those measures give you a real baseline. They also stop the project from becoming a vague demo where the AI pulls out a few fields and everyone agrees it looks impressive. Your first version won't handle every document perfectly. That's normal. Test it with real samples, including awkward ones, not only the clean examples people use in meetings. Watch where the extraction misses a field, where your instructions need clearer wording, and where the schema asks for data that nobody actually uses, then adjust one part at a time, add more samples, review the failures, tighten the process. Expand only after the first document type moves through its path reliably. Once you can see that full path from file to decision, document AI stops feeling like a black box, where this changes your work. The payoff isn't that your team processes more PDFs, it's that people stop searching through attachments for basic facts and spend their time deciding what needs attention. A document used to reach a folder or inbox and wait, now it can begin work. An invoice arrives, content understanding pulls the supplier, number, date, total, and purchase order reference. The process checks those fields against your records, then looks at the confidence for the results that carry risk. If the information passes your rules, a record enters dataverse and finance receives the item in the right queue. If the purchase order doesn't match or the total looks uncertain, a reviewer sees the document and the extracted fields together fixes what needs fixing and sends it forward. No scavenger hunt. A decision with an owner that same pattern reaches beyond finance. HR can pull details from onboarding documents. Procurement can root supplier paperwork, operations can process service requests, legal teams can track dates and obligations, customer service can turn incoming forms into cases. The document changes but the question stays the same. What action should this information trigger? There are limits and they matter. Blurry files, shifting layouts, unclear wording, access controls and missing process owners can still break the flow. AI doesn't remove those conditions, it exposes them faster. Content understanding provides the reading layer, power platform provides the action layer, people provide judgment when the stakes demand it. So don't start with can AI read this? Start with the harder question. And it does, who needs to decide and what happens next. Document AI earns its place when a field pulled from a file sends accountable work to the right next step. Subscribe to M365FM for practical guides on content understanding, power platform and the tools and mindset shaping the future of work.