Fix Microsoft 365 Document Processing Not Working
Why Microsoft 365 Document Processing Stops Working
Picture this: your team spent weeks configuring autofill columns in SharePoint, your prebuilt invoice model was running smoothly, and then one Monday morning , nothing. Documents sit in the library completely unprocessed, columns stay blank, and the error messages Microsoft shows you are vague at best. I've seen this exact scenario play out dozens of times across enterprise tenants, and the root cause is almost never what it looks like on the surface.
Microsoft 365 document processing , the suite of AI-powered services that handles everything from optical character recognition and document translation to eSignature and structured model extraction, runs on a pay-as-you-go billing model tied directly to an Azure subscription. That single dependency is where the vast majority of failures originate. If your Azure subscription lapses, hits a spending limit, or gets deprovisioned during a billing cycle review, every document processing service in your tenant goes dark simultaneously. Microsoft doesn't always surface this clearly in the SharePoint admin center; you just see models that won't run.
The second major source of breakage right now is the transition away from AI Builder credits. In October 2025, Microsoft announced a progressive end to AI Builder credits. If your organization was previously relying on AI Builder credit consumption to drive document processing workflows, which was common for Power Platform-integrated models, you're now in a migration window. Services that used to "just work" via credit allocation need to be re-mapped to the new pay-as-you-go meters.
There's also the per-user license sunset issue. Per-user licenses for document processing services are no longer available for purchase. Existing licenses still work while they're active, but once they expire, your tenant must switch to pay-as-you-go to continue. Organizations that didn't plan for this transition are finding their models suddenly fail when those licenses tick over to expired, even though the features themselves didn't change.
Government Community Cloud (GCC) tenants have a separate problem: pay-as-you-go licensing is not yet available for GCC organizations. If you're in a GCC environment and someone tells you to "just set up pay-as-you-go," that advice doesn't apply to you yet. Your path is to continue using per-user licenses until Microsoft makes pay-as-you-go available for GCC.
Beyond billing, I also see configuration drift, where a SharePoint document library had a model applied correctly but a site admin later changed library settings, moved files to a new site collection, or altered content type configurations, breaking the model's ability to process incoming documents. And then there are the simpler issues: unsupported file types sent to OCR, document translation hitting an unsupported language pair, or eSignature requests failing because the recipient's email domain is blocked by the organization's external sharing policy.
Whatever's broken for you, the steps below will get you back up and running. Browse all Microsoft fix guides →
The Quick Fix, Try This First
Before you spend an hour digging through SharePoint settings, do this one check first. It resolves the problem for a significant majority of the cases I work through with customers.
Open the Microsoft 365 admin center at admin.microsoft.com. In the left navigation, go to Settings > Org settings > Services and look for Document processing or search for "Syntex", Microsoft still uses both labels depending on your tenant's version. Click through to the pay-as-you-go setup page.
What you're looking for is a connected Azure subscription. If you see a banner that says "No Azure subscription connected" or the billing status shows as "Inactive," that's your answer. Every Microsoft 365 document processing service, autofill columns, document translation, eSignature, optical character recognition, content assembly, image tagging, taxonomy tagging, prebuilt models, structured and freeform models, and unstructured models, requires an active Azure subscription linked for billing. Without it, nothing processes.
If the subscription shows as connected but the status is "Suspended" or "Disabled," go directly to the Azure portal at portal.azure.com. Navigate to Subscriptions, find the linked subscription, and check its status. A subscription hits "Disabled" state typically 30 days after a payment failure or spending limit is reached. Re-enable it, verify your payment method is current, and within about 10–15 minutes your document processing services should resume automatically.
If you're running a trial or the subscription is active but you're still getting failures, check whether your organization consumed all its included monthly capacity. Through December 2025, Microsoft provided a limited amount of free monthly capacity for selected document processing services when pay-as-you-go billing was set up, a way to try the services at no cost. That included capacity expired at end of 2025. If you were in that free tier and never set up actual billing limits or confirmed your payment method covers overages, jobs will fail silently once the free capacity hits zero.
This is where every Microsoft 365 document processing troubleshooting session has to start. Sign into the Microsoft 365 admin center with a Global Administrator or SharePoint Administrator account. Go to Settings > Org settings > Services. Scroll down or search for Document processing. If you see a "Set up pay-as-you-go" prompt instead of an active billing status, the Azure subscription has never been linked or was disconnected.
Click Set up pay-as-you-go and walk through the wizard. You'll be asked to sign into the Azure portal, select an existing subscription, and choose a resource group. If you don't have an Azure subscription yet, you'll need to create one first at portal.azure.com, use a subscription tied to your organization's Azure billing account, not a personal pay-as-you-go trial.
For tenants where the subscription was previously connected but now shows errors, try disconnecting and reconnecting the subscription:
- In the Microsoft 365 admin center, navigate to the document processing billing settings page.
- Click Manage billing or Change subscription.
- Disconnect the current subscription.
- Wait 2–3 minutes, then reconnect using the same or a new Azure subscription.
After reconnecting, go to a SharePoint document library where you have a model applied. Upload a test document (a simple one-page PDF works well for OCR testing). Wait up to 5 minutes. If the model runs and populates columns, billing is fixed and you're done. If it still doesn't run, continue to Step 2.
One thing to watch: if your organization has multiple Azure subscriptions, say, one for development and one for production, make sure you're linking the right one. Document processing billing meters appear in the Azure subscription you specify, so your finance team needs to know which subscription to expect those charges on.
Even with billing fully working, document processing models won't run if they've been detached from the library or if the model itself is in an error state. This happens more often than you'd think, especially after SharePoint site migrations, content type hub republishing events, or tenant-level admin changes to managed metadata services.
Navigate to the SharePoint document library where your model should be running. Click the gear icon in the top right corner and select Library settings. Scroll down to the Document processing section. If it's absent entirely, the document processing feature hasn't been activated for this site collection, go to Site settings > Site collection features and activate Document processing from there first.
If document processing shows in library settings but your model isn't listed, go to the model management experience. From the library, click Automate > Document processing > View models (the exact menu path varies slightly depending on your SharePoint experience version). From the model management page, you can re-apply an existing model to the library.
For prebuilt models (invoices, receipts, contracts) and structured/freeform models, you can also navigate directly to your model in the Content center, typically at a URL like https://yourtenant.sharepoint.com/sites/ContentCenter. From there, go to My models, find the model, click Apply model, and re-select your target library.
After reapplying, upload a test document. You should see a processing indicator appear in the library view. If columns populate correctly within a few minutes, the model is working. If you see a red error icon on the document, right-click the document and check the processing status, it will often tell you exactly which extraction field failed and why.
Autofill columns use large language models to extract or generate content automatically, a genuinely useful feature when it works. When columns stay blank after documents are uploaded, there are three likely culprits: the column configuration, the document format, or a service throttle.
Start by checking the column configuration. In your SharePoint library, go to Library settings > Columns and click the autofill column in question. Verify the prompt is correctly defined and that the source field mapping makes sense for your document type. A common mistake I see is prompts that are too generic, something like "extract the date" when the document has five different dates. Be specific: "Extract the invoice due date from the bottom right of the first page."
For document format issues, note that autofill columns work best with text-extractable PDFs, Word documents (.docx), and PowerPoint files (.pptx). Scanned-image PDFs without embedded text will fail unless you first run them through optical character recognition. If your autofill columns are blank but the documents are scanned PDFs, set up OCR to run first, then configure autofill columns to run afterward using Library settings > Processing rules to set the order of operations.
Service throttling is the third cause. Microsoft 365 document processing meters have per-tenant rate limits, and if you bulk-uploaded a large batch of documents, some may have been throttled and never retried. To manually re-trigger processing:
# SharePoint Admin Center → Content services → Model usage
# Select your library → Re-run model on selected files
# Or use the SharePoint REST API to trigger reprocessing:
POST https://yourtenant.sharepoint.com/sites/YourSite/_api/machinelearning/publications/getbyuniqueid('your-model-id')/apply
Content-Type: application/json;odata=verbose
{
"TargetSiteUrl": "https://yourtenant.sharepoint.com/sites/YourSite",
"TargetWebServerRelativeUrl": "/sites/YourSite",
"TargetLibraryServerRelativeUrl": "/sites/YourSite/YourLibrary"
}After re-triggering, check the library again in 10–15 minutes. Columns should populate.
Optical character recognition and document translation are two of the most-used Microsoft 365 document processing services, and they each have their own failure patterns.
For OCR failures, the first thing to check is file format. OCR extracts printed or handwritten text from images, it processes image files (.jpg, .jpeg, .png, .tif, .tiff, .bmp) and image-based PDFs. It does not process text that's already machine-readable in a native Word or Excel file, because there's nothing to "recognize." If you're applying OCR to .docx files and nothing's happening, that's expected behavior. Make sure OCR is applied to the right library containing the right file types.
If OCR runs but the extracted text is garbled, check image resolution. Microsoft's OCR engine performs best on images at 150 DPI or higher. Anything below 100 DPI, which is common with photos taken quickly on phones, can produce unreliable results. Encourage users to scan at 200+ DPI when possible.
For document translation, the most common failure I see is language pair mismatch. Translation is available for all supported languages and dialects, but check Microsoft's current supported language list for document translation, not all language pairs have the same quality tier, and some less common dialects may not produce a translated copy at all, instead failing silently. Also confirm the source document is in the language you've specified. Running Spanish-to-English translation on a document that turns out to be written in Portuguese will produce errors or empty output.
Document translation creates a translated copy in the same SharePoint document library. If the copy isn't appearing, check the library's storage quota (Site settings > Storage metrics). A library at or near its quota will silently fail to create the translated copy. Also verify that the account triggering translation has at minimum Contribute permissions on the library, read-only accounts can't create the output file.
To manually kick off a document translation in SharePoint, right-click any document in the library, select Translate document, pick your target language, and click Translate. If this option doesn't appear in the context menu, the document translation service hasn't been set up at the tenant level, a Global Admin or SharePoint Admin needs to complete the setup steps in the Microsoft 365 admin center first.
If your document processing services abruptly stopped working and your licenses recently expired, this step is for you. Per-user licenses for document processing are no longer available for purchase, and once your existing per-user licenses expire, you must switch to pay-as-you-go to keep things running.
While your per-user licenses are still active, you retain the ability to apply unstructured models to libraries, create prebuilt, structured, and freeform models, upload content to libraries with applied models, run models on demand, use content assembly and taxonomy services, use content query and annotations, and use document library rules for automation. That's a solid feature set, but it all stops the day the licenses expire if pay-as-you-go isn't set up.
The migration path is straightforward but requires Global Admin or SharePoint Admin rights:
- Sign in to the Microsoft 365 admin center.
- Go to Settings > Org settings > Services > Document processing.
- Click Set up pay-as-you-go billing.
- Sign into the Azure portal when prompted.
- Select your Azure subscription and an appropriate resource group (create a new one named something like
rg-m365-docprocessing-prodfor clarity). - Accept the terms of service and complete the setup.
Once pay-as-you-go is active, your existing models, content center configurations, and library applications carry over automatically, you don't need to rebuild anything. The only change is how billing works: instead of a per-seat annual license, you're billed per use via Azure meters. Use the SharePoint cost calculator to model your expected monthly spend before committing. For most small-to-mid-size organizations running a few models on a few libraries, the pay-as-you-go costs are often lower than what per-user licenses were costing.
One thing that catches people off guard: if you had Power Platform flows or Power Automate workflows integrated with document processing models, check whether those integrations used AI Builder credits. As of October 2025, Microsoft announced the progressive end of AI Builder credits. Workflows consuming AI Builder credits for document intelligence actions need to be updated to use the new pay-as-you-go meters instead. Audit your Power Automate flows in the Power Platform admin center under Environments > Resources > Flows and look for any flow using "AI Builder" actions connected to document processing.
Advanced Troubleshooting for Microsoft 365 Document Processing
Diagnosing via the Microsoft 365 Admin Center, Usage Reports
When individual library fixes aren't resolving the issue at scale, go to the usage reporting layer. In the Microsoft 365 admin center, navigate to Reports > Usage. Microsoft 365 document processing services generate usage data that appears under the SharePoint reporting section. If you see zero processed documents over the last 30 days on a library that should be active, you have a service-level problem, not a library-level one.
Cross-reference this with your Azure subscription's billing dashboard. In the Azure portal, go to Cost Management + Billing > Cost analysis and filter by the resource group you assigned to document processing. Look for the specific service meters:
SharePoint Document Processing - OCR PagesSharePoint Document Processing - Translation PagesSharePoint Document Processing - Model TransactionsSharePoint eSignature - Requests
If you see zero billing activity in Azure for a period when documents were definitely uploaded to SharePoint, the service pipeline between SharePoint and the Azure billing meters is broken, which typically means the pay-as-you-go registration needs to be refreshed as described in Step 1.
SharePoint ULS Logs and Correlation IDs
When a document fails to process, SharePoint generates a correlation ID. Find it by clicking the failed document and looking at the processing status tooltip, it'll say something like "Processing failed. Correlation ID: a3b7c291-xxxx-xxxx-xxxx-d4e8f0912345." Copy this ID and bring it to your SharePoint admin. They can query the Unified Logging Service (ULS) logs via the SharePoint Online Management Shell:
Connect-SPOService -Url https://yourtenant-admin.sharepoint.com
# Get-SPOSiteHealth can help surface site-level processing issues:
Get-SPOSite -Identity "https://yourtenant.sharepoint.com/sites/YourSite" | Select-Object *For deeper log access, Microsoft 365 audit logs in the Microsoft Purview compliance portal will show document processing events. Go to Microsoft Purview > Audit > Search and filter by activity type "Document processing" to see a timeline of all model runs, failures, and billing events.
Custom Power Platform Environment Configuration
If your team uses structured or freeform models in a custom Power Platform environment (rather than the default environment), there's an additional configuration step that's easy to miss. Per Microsoft's official documentation, custom Power Platform environments require specific setup for document processing models to function. In the Power Platform admin center, navigate to Environments > [Your Environment] > Settings > Features and verify that AI Builder is enabled for that environment. Additionally, the Azure subscription linked for pay-as-you-go billing in Microsoft 365 must be associated with the same Azure Active Directory tenant as the Power Platform environment, cross-tenant setups break the billing authorization chain.
Taxonomy and Content Type Hub Issues
Taxonomy tagging and content query features depend on the SharePoint Taxonomy Service being healthy. If your managed metadata service is in a degraded state, which you can check in the SharePoint admin center under Content services > Term store, taxonomy tagging will silently fail to apply tags even while reporting successful processing. Republish term sets from the term store admin and re-trigger document processing on affected documents.
If you've verified Azure billing is active, models are applied correctly, and individual service fixes haven't resolved the issue after 24 hours, it's time to open a support ticket. Specifically escalate to Microsoft if: (1) your pay-as-you-go setup shows active in the admin center but Azure meters show zero activity; (2) eSignature requests are failing with error code 5xx for all users; or (3) you're in a GCC environment and experiencing unexpected service degradation. Use Microsoft Support to open a ticket, select "Microsoft 365" as the product and "Document processing / Syntex" as the feature. Include your tenant ID, the affected SharePoint site URL, and any correlation IDs you've collected.
Prevention & Best Practices for Microsoft 365 Document Processing
Getting document processing working is one thing. Keeping it working reliably at scale is another challenge entirely. Here's what I tell every organization that wants to run these services in production without constant firefighting.
Set up Azure cost alerts the moment you go live with pay-as-you-go billing. In the Azure portal under Cost Management + Billing > Budgets, create a budget for your document processing resource group with alerts at 50%, 80%, and 100% of your expected monthly spend. This catches unexpected spikes, like someone accidentally applying a prebuilt model to a library containing years of archived PDFs, before they become a surprise invoice line item.
Don't apply models to libraries with large existing document backlogs without planning for it. When you apply a model or enable autofill columns on a library for the first time, Microsoft 365 document processing will attempt to process all existing documents in the library, not just new ones going forward. If that library has 10,000 documents, you're triggering 10,000 model runs immediately. Instead, set the model to process new documents only first (check the model application settings), verify it works correctly on a sample, then make a deliberate decision about whether to backfill historical documents.
Keep your SharePoint admin team informed about the AI Builder credits end-of-life timeline. Any Power Automate flows that relied on AI Builder credits for document intelligence need to be inventoried and migrated. The progressive end announced in October 2025 means this is an ongoing transition, not a single cutoff date, but don't wait until credits are fully gone to start the migration.
For GCC organizations, watch the Microsoft 365 roadmap at microsoft.com/microsoft-365/roadmap and filter by "GCC" for updates on pay-as-you-go availability. When it becomes available, plan your migration from per-user licenses before existing licenses expire to avoid any service gap.
- Set Azure budget alerts at 50% and 80% of expected monthly spend on your document processing resource group, catches runaway batch jobs before they become big bills.
- Run the SharePoint cost calculator before applying models to large libraries, especially libraries with historical document backlogs that will all process at once on initial model application.
- Audit all Power Automate flows using AI Builder actions now, the progressive end of AI Builder credits affects any flow that used credit-based document processing, and migrating proactively is far less painful than emergency triage.
- Create a dedicated SharePoint content center site (if you haven't already) to centralize all model management, it makes model reapplication, version control, and usage monitoring dramatically easier when something breaks.
Frequently Asked Questions
Why did my Microsoft 365 document processing models stop working after they were fine for months?
The most common cause is a change to the Azure subscription linked for pay-as-you-go billing, a payment failure, a subscription hitting a spending limit, or an Azure admin suspending the subscription during a cost review. Open the Azure portal and check the health of the subscription under Subscriptions > [Your Sub] > Overview. A status of anything other than "Active" will kill all document processing services. The second most common cause is expiry of per-user licenses, if your org was on per-user licenses that recently expired, you'll need to set up pay-as-you-go billing in the Microsoft 365 admin center to continue.
We're a GCC organization, why can't we set up pay-as-you-go for document processing?
Pay-as-you-go licensing for Microsoft 365 document processing is not yet available for Government Community Cloud (GCC) organizations. This is a current platform limitation, not something you can work around through admin settings or licensing changes. GCC organizations can continue to purchase and use per-user licenses in the meantime. Keep an eye on the Microsoft 365 Government roadmap for an announcement on GCC pay-as-you-go availability, there's no published date as of April 2026, but Microsoft has indicated it's coming.
What happened to AI Builder credits, and do I need to do anything?
In October 2025, Microsoft announced the progressive end of AI Builder credits. If your organization was using AI Builder credits to run document processing tasks, particularly within Power Automate flows, those credits are being phased out. You'll need to migrate affected flows to use the new pay-as-you-go billing meters tied to your Azure subscription instead. Audit your Power Automate environment under Power Platform admin center > Environments > Resources > Flows and identify any flows using AI Builder document intelligence actions. Rebuilding those connections to bill through pay-as-you-go is the supported migration path.
My autofill columns ran fine on a test document but now won't process new uploads. What changed?
A few things can cause this. First, check if the document library hit a processing throttle, bulk uploads can back up the processing queue and newer documents get stuck. Try manually re-triggering processing by selecting the affected documents in the library, clicking Automate in the toolbar, and running the model on demand. Second, check if the file types of the new uploads differ from your test document, autofill columns using LLMs work on text-extractable documents; scanned image PDFs require OCR to run first. Third, verify your Azure subscription billing is still active; a lapsed payment can cause a silent processing halt that looks exactly like this symptom.
How do I know how much my document processing services are actually costing me each month?
Open the Azure portal and navigate to Cost Management + Billing > Cost analysis. Filter by the resource group you assigned when setting up pay-as-you-go billing for Microsoft 365 document processing. You'll see line items for each service meter, OCR pages processed, model transactions, translation pages, eSignature requests, and so on. For forward-looking planning, use the SharePoint cost calculator available from the Microsoft 365 admin center's document processing billing settings page. Plug in your estimated monthly volumes per service and it'll generate a projected cost breakdown. I strongly recommend doing this exercise before any large-scale rollout.
Can I use Microsoft 365 document processing eSignature with external recipients outside my organization?
Yes, eSignature is designed to send electronic signature requests to both internal and external recipients, keeping the underlying document within Microsoft 365 while it's being reviewed and signed. However, if your organization has restrictive external sharing policies configured in the SharePoint admin center, specifically policies that block external access to SharePoint content, eSignature requests to external recipients may fail. Check your SharePoint external sharing settings under SharePoint admin center > Policies > Sharing and ensure the sharing level allows the eSignature workflow to send requests to external email addresses. Also confirm the recipient's email domain isn't on your organization's blocked domains list.