Fix Microsoft 365 Document Processing Issues
Why This Is Happening
I've worked with Microsoft 365 document processing across dozens of enterprise tenants, and the same scenario plays out almost every time: an IT admin sets up what was previously called Microsoft Syntex , now officially rebranded as document processing for Microsoft 365 , and within a week, users start hitting walls. Models won't apply. Pay-as-you-go billing won't activate. The autofill columns aren't populating. The OCR results are empty. And Microsoft's error messages? Absolutely useless. You get a generic "something went wrong" banner in SharePoint that tells you nothing about whether the problem is licensing, Azure billing configuration, tenant permissions, or a model that just wasn't trained correctly.
Here's the core issue most people run into: Microsoft 365 document processing is a pay-as-you-go service billed through an active Azure subscription. That's a significant architectural shift from the old per-user licensing model. If your Azure subscription isn't connected properly, or if the billing link exists but the correct resource group and region aren't configured, none of the document processing services will function, full stop. No autofill columns. No document translation. No eSignature. Nothing.
The second most common issue I see is confusion around the legacy per-user license situation. Per-user licenses for these services are no longer sold, but if your organization bought them before the cutoff, they're still valid until expiration. The problem is that admins often don't realize they're running on an expiring per-user license, and when it lapses without a pay-as-you-go fallback in place, all processing just stops. No warning. No graceful degradation. One day it works, the next day it doesn't.
There's also a specific regional availability gap that catches people off guard. Government Community Cloud (GCC) tenants don't have access to pay-as-you-go licensing yet, they're still on the per-user model. If your organization moved from a commercial tenant to a GCC environment, or if you're managing a mixed tenant estate, document processing behavior will be completely inconsistent across those environments, and the reason isn't obvious from the admin center.
Finally, the AI Builder credits end-of-life announcement from October 2025 has created a wave of confusion. Many organizations had workflows built on AI Builder credits that fed into document processing pipelines. Those credits are being phased out progressively, and if your setup relied on them, your processing models may have silently stopped working even though everything looks fine in the admin portal.
Whether you're setting up Microsoft 365 document processing for the first time or fixing a broken deployment, this guide covers every layer of the problem. Browse all Microsoft fix guides →
The Quick Fix, Try This First
Before you spend an hour in the Azure portal or dig into SharePoint admin settings, do this one check. It resolves about 60% of Microsoft 365 document processing failures I've seen.
Go to the Microsoft 365 admin center at admin.microsoft.com. In the left navigation, expand Settings and click Org settings. Scroll down and select SharePoint, then look for the Document processing section. You'll see whether pay-as-you-go billing is enabled and which Azure subscription is linked.
If you see "Pay-as-you-go billing is not set up", that's your answer. Nothing works until billing is connected. Click Set up pay-as-you-go billing, sign in with an account that has Azure Subscription Owner or Contributor rights, select your Azure subscription, choose a resource group and a region, then confirm. The provisioning takes about 5–10 minutes. After that, go back to a SharePoint document library, open a file, and try applying a document processing model again.
If billing shows as active but things still aren't working, the next most likely culprit is that the services themselves haven't been individually enabled. In the same admin center, navigate to Setup > Use your apps > Document processing. Each service, autofill columns, document translation, eSignature, OCR, content assembly, image tagging, taxonomy tagging, has its own toggle. It's very common for admins to enable pay-as-you-go billing but leave individual services switched off. Turn on the specific service you need and wait a few minutes for it to propagate across the tenant.
If you're on a GCC tenant, stop here, pay-as-you-go isn't available for your environment yet. You'll need to continue using per-user licenses until Microsoft rolls out the option.
This is the foundation. Without a properly linked Azure subscription, every document processing service returns errors or simply does nothing, and the user-facing error messages won't tell you that billing is the issue.
Sign into admin.microsoft.com with a Global Administrator account. Navigate to Settings > Org settings > SharePoint. Under the Document processing section, click Manage pay-as-you-go billing.
On the billing setup screen, you'll be asked to select an Azure subscription. Use an account that has Owner or Contributor access on the Azure subscription, a Global Admin account alone isn't enough if it doesn't have Azure RBAC rights. Select your subscription, then choose a Resource group and a Region. The region you choose here affects data residency, so pick the Azure region geographically closest to your SharePoint tenant's primary data location.
# Verify your Azure subscription is active using Azure CLI:
az account show --query "{Name:name, State:state, ID:id}" --output table
# Check you have the right role assigned:
az role assignment list --assignee your-upn@contoso.com --output tableAfter saving, the billing status in the admin center should change to Active within 5–10 minutes. If it stays stuck on "Pending," check whether your Azure subscription has any spending limits applied, a $0 spending cap on a free or trial subscription will block provisioning entirely.
Success indicator: The billing page shows "Active" with your subscription name, resource group, and region listed. You should also see a cost estimate section appear, confirming the meter connection is live.
Paying for the subscription doesn't automatically turn on every service. Each of the ten document processing services has a separate activation toggle. This catches a lot of people because the Microsoft documentation describes the billing setup and the service activation as two different procedures, and most admins stop after completing the billing step.
In the Microsoft 365 admin center, go to Setup in the left navigation. Click Use your apps, then search for or scroll to Document processing. You'll land on a panel that lists all available services grouped by type.
For each service you want to use, click the service name and toggle it to On. The full list of pay-as-you-go services you can activate here includes: Autofill columns, Document translation, eSignature, Optical character recognition (OCR), Content assembly, Image tagging, Taxonomy tagging, Prebuilt document processing, Structured and freeform document processing, and Unstructured document processing.
There are also supporting features that don't require separate activation but are worth confirming are enabled: Content query, Annotations, Content processing rules, Solution accelerators, and Taxonomy tools.
Don't enable services you don't need right now. Each active service adds to your potential monthly bill since billing is per-transaction. If your only use case is extracting text from scanned invoices, just enable OCR and prebuilt models, leave image tagging and taxonomy tagging off until you have a specific need.
Success indicator: Navigate to a SharePoint document library, click on a document, and open the Document processing panel from the right-side details pane. You should now see the enabled services listed as available options rather than greyed-out or missing.
Once billing and service activation are sorted, the next most common failure point is a model that either wasn't trained correctly or was created under the old per-user license system and hasn't been migrated properly to the pay-as-you-go context.
To check a model's status, go to the Content center in SharePoint, this is the dedicated site for managing document processing models. If you don't have a content center, you'll need to create one: go to SharePoint admin center > Active sites > Create > Browse more templates > Content center.
Inside the content center, click Models in the top navigation. For each model, check the Status column. Models in a "Training required" or "Error" state need attention. Common reasons a model fails at this stage:
- Fewer than 5 example documents were used during training (the minimum for any structured, freeform, or unstructured model)
- The training documents were too visually inconsistent, OCR can't reliably extract the same field from 10 wildly different invoice layouts without structured model training
- The model was applied to a library in a region that doesn't match the billing region you configured in step 1
# Use SharePoint PnP PowerShell to check model application status:
Connect-PnPOnline -Url "https://contoso.sharepoint.com/sites/ContentCenter" -Interactive
Get-PnPSyntexModel | Select-Object Title, ModelType, Status, LastModifiedSuccess indicator: Each model in the content center shows a green Published status and lists at least one document library it's applied to. When you upload a test document to an applied library, the model should process it within 30–60 seconds and populate the associated metadata columns.
Autofill columns are one of the most requested document processing features, they use large language models to automatically extract or generate content and fill SharePoint metadata columns as documents land in a library. When they stop working or never worked at all, there are three likely causes.
Cause 1, The column isn't configured as an autofill column. Regular SharePoint columns don't become autofill columns automatically. You have to explicitly configure them. In the document library, click + Add column and either create a new column or select an existing one, then choose Set up autofill in the column settings. Write a clear natural-language prompt that describes what you want the LLM to extract, for example, "Extract the total invoice amount from this document" or "Summarize the key parties listed in this contract in one sentence."
Cause 2, Documents were uploaded before the autofill column was configured. Autofill columns only trigger for documents uploaded after the column was set up and activated. For existing documents, you need to manually trigger processing. Select the files in the library, click Automate in the command bar, then choose Run document processing or use the Process now option from the document's right-click context menu.
Cause 3, The LLM prompt is too vague or too specific. I've seen autofill columns silently return blank results because the prompt asked for something the model couldn't reliably find across different document formats. Test your prompt on at least 10 varied documents. If more than 20% return blank, rewrite the prompt to be more explicit about document type and expected format.
# Trigger on-demand processing via PnP PowerShell for existing library files:
Connect-PnPOnline -Url "https://contoso.sharepoint.com/sites/Invoices" -Interactive
$items = Get-PnPListItem -List "Documents" -PageSize 100
foreach ($item in $items) {
Invoke-PnPSyntexClassifyAndExtract -FileUrl $item["FileRef"]
}Success indicator: Upload a fresh test document to the library. Within 60–90 seconds, the autofill columns should populate with extracted values. Check the document's version history, if processing ran, you'll see a system-generated version comment noting the autofill update.
eSignature and document translation are two services with slightly different setup requirements that often get overlooked.
For eSignature: Beyond enabling the service in the admin center, eSignature requires that the SharePoint library where you initiate signature requests has versioning enabled. This is a hard dependency, if versioning is off, the eSignature workflow will fail silently or throw a generic error when you try to send a request. Enable versioning by going to the document library > Library settings (gear icon > Library settings) > Versioning settings > select Create major versions > Save.
Additionally, eSignature works only with documents stored in SharePoint document libraries. It does not work with files in OneDrive for Business, Teams channel file tabs pointing to external locations, or SharePoint lists. If users are trying to send a signature request from the wrong content source, they'll hit a dead end.
For Document translation: Translation creates a translated copy of the document in the same SharePoint library, preserving the original file's formatting and structure. The most common setup error is trying to translate a file type that isn't supported. Translation works with Word documents (.docx), PowerPoint presentations (.pptx), Excel workbooks (.xlsx), PDF files, plain text, and HTML. It does not work with older Office formats like .doc, .xls, or .ppt, those need to be converted first.
To trigger a translation, right-click a document in the library and select Translate document. Choose the target language from the dropdown, Microsoft supports all the languages listed in the official documentation, including regional dialects. The translated copy appears in the same library folder within a few minutes depending on document size.
# Check if a file format is eligible for translation:
# Supported extensions: .docx, .pptx, .xlsx, .pdf, .txt, .html, .htm
# If your file is .doc or .xls, convert it first:
# Via PowerShell with SharePoint PnP:
Convert-PnPFile -ServerRelativeUrl "/sites/Legal/Documents/OldContract.doc" -ToFormat DocxSuccess indicator: For eSignature, a signing request email arrives at the recipient's inbox with a link to review and sign the document within Microsoft 365. For translation, a new file appears in the library with the target language appended to the filename (e.g., "Contract_FR.docx") and the original file remains unchanged.
Advanced Troubleshooting
If the steps above didn't resolve your Microsoft 365 document processing issues, you're likely dealing with something at the tenant configuration layer, an Azure billing anomaly, or an enterprise permission problem. Here's how to go deeper.
Check the SharePoint Unified Audit Log for processing errors. Most document processing failures generate audit events that never surface in the SharePoint UI. In the Microsoft Purview compliance portal (compliance.microsoft.com), go to Audit > Search. Filter by Activity: search for "SyntexModelApplied" and "SyntexProcessingError." Set the date range to the last 7 days and filter by the affected SharePoint site URL. Processing errors will show up with a ResultStatus of "Failed" and a Details field that contains the actual underlying error code, things like ModelNotFound, BillingAccountNotLinked, or RegionMismatch that you'd never see in the normal UI.
Verify Azure meter registration. In the Azure portal (portal.azure.com), go to your subscription > Cost Management + Billing > Cost analysis. Filter by service name "Microsoft 365 Document Processing." If you see zero entries after at least 24 hours of use, the Azure billing meter wasn't registered correctly during setup. This is rare but happens when the resource group specified during billing setup doesn't exist yet in the selected region. Fix it by going back to the Microsoft 365 admin center, removing the billing connection, and re-establishing it with a properly provisioned resource group.
For domain-joined enterprise environments with Conditional Access policies: Some CA policies block the service principals that Microsoft 365 document processing uses to authenticate against Azure. In Azure Active Directory (now called Microsoft Entra ID), go to Enterprise applications and search for "Microsoft Syntex", note that the service principal still uses the Syntex name internally even after the rebrand. Confirm the service principal isn't blocked by a policy requiring device compliance or a specific named location. If it is, add a CA policy exclusion for that specific service principal.
AI Builder credits end-of-life impact: If your document processing models were built using Power Automate flows that called AI Builder actions (form processing, object detection, prediction), those actions are affected by the AI Builder credits phase-out announced in October 2025. Audit your Power Automate flows for any actions prefixed with "AI Builder" and replace them with the native Microsoft 365 document processing API calls or SharePoint prebuilt model triggers. This migration isn't automatic.
# Find all Power Automate flows in your tenant that use AI Builder actions:
# Use Power Platform CLI (pac):
pac flow list --environment Default-YourEnvironmentID | grep -i "AI Builder"
# Or via PowerShell with Power Apps admin module:
Get-AdminFlow | Where-Object {$_.Properties.Definition -match "aibuilder"}Custom Power Platform environment for structured/freeform models: If your organization runs structured or freeform document processing models in a custom Power Platform environment (not the default Dataverse environment), there are extra configuration steps documented separately. You need to ensure the custom environment is linked to the same Azure region as your document processing billing setup, and that the environment has the AI Builder resource provisioned. Mismatches here produce errors that look identical to billing problems but are actually environment routing failures.
Prevention & Best Practices
I know from experience that most Microsoft 365 document processing outages are self-inflicted, not malicious, just the result of configuration drift over time or a billing account change that nobody documented. Here's how to keep things stable.
Document your billing configuration in writing. The Azure subscription ID, resource group name, and region you selected during pay-as-you-go setup are not visible anywhere obvious after setup completes. Write these down in your IT runbook immediately. When someone leaves the team or your Azure subscription gets reorganized, knowing exactly which subscription powers document processing saves hours of debugging.
Set up Azure cost alerts for document processing meters. In Azure Cost Management, create a budget alert specifically for the Microsoft 365 Document Processing service meter. Set a threshold at 80% of your expected monthly spend. If processing volume suddenly spikes, often caused by a runaway automation flow triggering repeated model runs on the same files, you'll get an email before the bill explodes rather than after.
Monitor per-user license expiry dates proactively. If your organization still has active per-user licenses from before the purchase cutoff, set a calendar reminder 90 days before each license's expiry. You need time to confirm pay-as-you-go is properly configured before the per-user license lapses. A gap between expiry and pay-as-you-go activation means processing stops, and depending on your document workflows, that can mean contract review queues backing up or invoice extraction pipelines going dark.
Train models with diverse, representative document samples. The quality of prebuilt, structured, freeform, and unstructured model outputs is directly tied to the quality of your training data. Use at least 20–30 example documents per model (well above the 5-document minimum) and make sure they represent the full range of formats, layouts, and quality levels you'll encounter in production. A model trained only on clean, perfectly formatted PDFs will perform poorly on scanned paper documents with skewed orientations or poor scan quality.
- Enable spending limits and cost alerts in Azure Cost Management before going live with any high-volume processing workflow
- Use the free included capacity window (available through December 2025) to fully test and validate all models before processing real production documents
- Assign a dedicated SharePoint site collection administrator to the Content Center site, having a clear owner prevents the "nobody knows how this was set up" problem
- Run monthly audits of applied models across document libraries to catch orphaned model applications pointing to deleted or renamed content types
Frequently Asked Questions
Microsoft 365 document processing was working fine and just stopped, what happened?
The most common cause of a sudden stop is that the Azure subscription linked to your pay-as-you-go billing either expired, hit a spending cap, or was reassigned to a different billing account. Sign into the Azure portal and confirm your subscription is in an "Active" state. If it's "Disabled" or "Past Due," that's your answer, reinstate the subscription and document processing should resume within an hour. If the subscription looks fine, check the Microsoft 365 service health dashboard at admin.microsoft.com/Adminportal/Home#/servicehealth for any active incidents affecting SharePoint or document processing services in your region. Microsoft-side outages are more common than most people realize.
What's the difference between prebuilt models, structured models, and unstructured models in document processing?
Prebuilt models are ready-to-use and pre-trained by Microsoft to handle common document types like invoices, receipts, contracts, and business cards, you don't train them yourself, just apply them to a library. Structured and freeform models require you to provide example documents and label the fields you want to extract; they're best when your documents have consistent layouts with specific data points you need to capture, like purchase order numbers or contract dates. Unstructured models are designed for documents that vary widely in format, like legal filings or research reports, where the goal is classifying what type of document something is and extracting whatever content is present, even without a predictable structure. Start with prebuilt models if they cover your document type; they're the fastest to deploy and require no training.
Does Microsoft 365 document processing work for GCC (Government Community Cloud) tenants?
Not on pay-as-you-go billing, not yet. GCC tenants are currently excluded from the pay-as-you-go licensing model that commercial tenants use. GCC organizations can still purchase and use per-user licenses for document processing services, and those continue to work. Microsoft has indicated that pay-as-you-go will become available for GCC tenants in a future update, but no specific date has been announced. If you're managing a GCC environment, keep your per-user licenses active and watch the Microsoft 365 roadmap at microsoft.com/en-us/microsoft-365/roadmap for GCC availability updates.
The autofill columns are enabled but returning blank values for most documents, how do I fix it?
Blank autofill results almost always come down to prompt quality. The LLM that powers autofill columns needs a clear, specific instruction to know what to look for. Instead of a prompt like "Get the date," try "Extract the document date from the header or first paragraph of this document, it is typically formatted as MM/DD/YYYY or Month DD, YYYY." Test your prompt against at least 10 different documents from your library before applying it at scale. Also check that the documents themselves contain machine-readable text, scanned image PDFs that haven't been through OCR will return blank results for any text-based autofill prompt since the LLM can't read image pixels. Enable OCR processing on those libraries first to extract the text layer before autofill runs.
Can I still use per-user licenses if I already have them, or do I have to switch to pay-as-you-go right now?
If you have active per-user licenses, you can keep using them until they expire. You can still apply unstructured models to libraries, create and run prebuilt, structured, and freeform models, use content assembly and taxonomy services, and run models on demand, all the core functionality is available under the existing per-user license. What you can't do is purchase new per-user licenses for document processing, those are no longer sold. Once your current licenses expire, switching to pay-as-you-go billing is the only path to continuing service. Set up the Azure billing link before your licenses expire to avoid any processing gap, since activation can take a few minutes to propagate.
How does pay-as-you-go pricing actually work, am I charged per document, per model, or per service?
Billing is structured as service meters in Azure, and the unit varies by service type. OCR is charged per page processed. Document translation is charged per character translated. Autofill columns are charged per column fill operation, meaning each time the LLM evaluates a document against a configured autofill column, that's one billable transaction. Prebuilt, structured, and freeform model processing is charged per document page run through the model. eSignature is billed per signature request initiated. You can use the SharePoint cost calculator linked in the Microsoft 365 admin center billing section to estimate monthly costs based on your expected document volumes before committing to full production deployment, it's genuinely useful and I'd recommend running through it before enabling any high-volume workflows.