Fix Microsoft 365 Document Processing Errors
Why This Is Happening
I've seen this exact situation play out dozens of times: an IT admin or SharePoint power user sets up Microsoft 365 document processing , maybe they're finally trying to get autofill columns working on invoice libraries, or they want OCR pulling text out of scanned PDFs , and then nothing works. The feature just sits there greyed out, or a model refuses to apply to a library, or billing throws a cryptic Azure error that tells you absolutely nothing useful.
Here's the honest truth: Microsoft 365 document processing (what used to be called Microsoft Syntex before the rebranding) has a setup chain with more dependencies than most admins expect. If even one link in that chain is broken, the Azure subscription isn't linked properly, the pay-as-you-go billing meter isn't enabled for the right service, or the SharePoint admin center is pointing at the wrong environment, everything downstream silently fails.
The rename itself has caused confusion too. If you're searching for "Syntex" in the Microsoft 365 admin center right now, you won't find it under that name anymore. These are now called document processing services for Microsoft 365, and they live under a different navigation path than where older guides told you to look. Microsoft made that switch official, and a lot of the community documentation hasn't caught up.
The other major source of pain right now: the per-user license model is effectively dead. Microsoft stopped selling new per-user licenses. If you have existing licenses, they still work, for now, but you can't buy new ones, and once they expire you're on pay-as-you-go or you're stuck. A lot of organizations are hitting that wall and discovering their document processing workflows have quietly broken because no one set up Azure billing before the licenses lapsed.
It's also worth knowing that Government Community Cloud (GCC) tenants are in a completely different situation, pay-as-you-go isn't available for GCC yet, which means certain services simply cannot be activated regardless of what you configure. If you're on a GCC tenant and following standard setup guides, that's likely why nothing is working for you.
The error messages Microsoft surfaces in these scenarios are genuinely unhelpful. You'll see generic "something went wrong" toasts in SharePoint, permission errors in the Power Platform admin center that don't explain the actual requirement, and Azure billing errors that drop you into documentation that assumes you already know what you're doing. I know this is frustrating, especially when document processing sits at the center of a workflow your team depends on. Let's fix it.
The Quick Fix, Try This First
Before you go through all five detailed steps below, try this single check first. It resolves the majority of document processing activation failures I've encountered.
Open the Microsoft 365 admin center at admin.microsoft.com. In the left navigation, go to Settings > Org settings, then click the Services tab. Scroll down and look for Document processing (not Syntex, that name is gone). If you don't see it listed, you need the SharePoint admin center instead: go to admin.microsoft.com, expand Admin centers in the left rail, and click SharePoint. Inside the SharePoint admin center, navigate to Settings and look for Document processing.
Once you find the document processing settings page, look for the Pay-as-you-go billing section. If it shows "Not configured" or has no Azure subscription listed, that's your problem right there. Every single document processing service, OCR, autofill columns, eSignature, document translation, image tagging, taxonomy tagging, all of it, requires pay-as-you-go billing to be connected to an active Azure subscription. Without that connection, the services are present in the UI but completely non-functional.
If you have an Azure subscription ready to link, click Set up billing, sign in with a Global Admin or Billing Admin account, and follow the prompts to connect your Azure subscription. The process takes about three minutes. After saving, wait up to 15 minutes for the billing connection to propagate before testing any document processing feature. Most people give up after 60 seconds and assume it's broken, give it the full 15.
This is the foundational step. Every document processing feature in Microsoft 365, autofill columns, optical character recognition, eSignature, document translation, content assembly, image tagging, taxonomy tagging, prebuilt models, structured models, freeform models, and unstructured models, operates on the pay-as-you-go billing model. None of them work without a valid Azure subscription attached.
Navigate to the SharePoint admin center: from admin.microsoft.com, go to Admin centers > SharePoint. In the left navigation, click Settings. Look for the Document processing (pay-as-you-go) entry. Click it to open the billing configuration panel.
You need to see three green checkmarks here: an active Azure subscription, a resource group, and a region. If any of these show as missing or show an error state, click Edit billing and re-run the setup wizard. You'll need to be a Global Admin or SharePoint Admin, and the Azure account used for billing needs to have at minimum Contributor role on the subscription.
If the wizard fails midway through, check whether your Azure subscription has Microsoft.SharePoint registered as a resource provider. In the Azure portal, go to your subscription, then Settings > Resource providers, search for Microsoft.SharePoint, and click Register if the status shows anything other than "Registered." This is a commonly missed prerequisite.
# PowerShell: Check if SharePoint resource provider is registered
Connect-AzAccount
Get-AzResourceProvider -ProviderNamespace "Microsoft.SharePoint" | Select-Object ProviderNamespace, RegistrationStateIf the output shows NotRegistered, run: Register-AzResourceProvider -ProviderNamespace "Microsoft.SharePoint" and wait 5–10 minutes before retrying the billing wizard.
Linking your Azure subscription activates billing, but individual services still need to be switched on. This is a step that catches a lot of people because the billing setup completion screen implies everything is ready, it's not. You've just enabled the payment mechanism. The services themselves have individual toggles.
Still in the SharePoint admin center under Settings > Document processing, scroll past the billing section. You'll see a list of document processing services, each with its own enable/disable toggle. Services that aren't toggled on won't be available to users, won't appear in library settings, and won't process anything even if billing is configured perfectly.
Go through each service your organization needs and toggle it on explicitly:
- Autofill columns, for LLM-based metadata extraction in document libraries
- Document translation, for translated copies in SharePoint libraries
- eSignature, for electronic signature workflows
- Optical character recognition (OCR), for extracting text from images and scanned PDFs
- Prebuilt document processing, for contracts, invoices, and receipts
- Structured and freeform document processing, for custom form extraction models
- Unstructured document processing, for document classification
After toggling services on, allow up to 20 minutes before testing. SharePoint's service provisioning isn't instant, and testing immediately after enabling is a reliable way to convince yourself it's broken when it just hasn't propagated yet. If a service still doesn't appear in a document library after 30 minutes, try signing out of SharePoint and back in, or testing in a private browser window to rule out session caching.
If billing is set up and services are enabled but your document processing model won't train, won't publish, or won't apply to a library, you're dealing with a different class of problem. This is where things get more specific to which model type you're using.
For unstructured models (formerly called "teaching method" models in Syntex), you build them in the Content Center site. If the model won't publish to a library, confirm the Content Center was created correctly. In the SharePoint admin center, go to Content services > Content center and verify a Content Center site exists. If it was created before the Syntex-to-document-processing rename, it may need to be repointed. Try creating a new Content Center site and migrating your model there.
For structured and freeform models, training happens inside Power Automate. A common failure point here is that the Power Platform environment used for model training doesn't have the AI Builder capacity connected. Go to make.powerautomate.com, select the correct environment in the top-right dropdown, then go to AI Hub > AI models. If you see a message about insufficient capacity or AI Builder credits, this is directly related to Microsoft's October 2025 announcement about the progressive end of AI Builder credits, the billing for these models now flows through the document processing pay-as-you-go meter instead.
# Verify your Power Platform environment is set up correctly
# Run this from SharePoint admin center PowerShell module
Connect-SPOService -Url https://[yourtenant]-admin.sharepoint.com
Get-SPOTenant | Select-Object -Property ContentTypeSyncSiteTemplatesList, AIBuilderEnabledWhen a model successfully applies to a library, you'll see a new Models column in the library view and a notification banner at the top of the library saying the model is active. If you don't see that banner, the model hasn't applied, don't assume silence means success.
OCR is one of the most-used document processing features and one of the most commonly broken ones in my experience. The symptom is clear: you upload a scanned PDF or an image file to a SharePoint library that has OCR enabled, and no text appears in the extracted text column. No error, no indication anything went wrong, just silence.
First, confirm OCR is enabled at the tenant level (Step 2 above) and also enabled at the library level. Navigate to the document library, click Library settings (the gear icon > Library settings, or the settings option in the modern library toolbar), then look for Optical character recognition in the settings list. Toggle it on if it's off. Note that the OCR setting is per-library, enabling it in the admin center makes it available, but each library needs its own activation.
Next, check the file type. Microsoft 365 OCR processes images (JPEG, PNG, TIFF, BMP, GIF) and PDF files. It does not process files where the text is already selectable, OCR only runs when the content layer is absent or purely image-based. If you're uploading a native Word or PDF with actual text layers, OCR won't run because there's nothing to extract.
If OCR is enabled and the file type is correct but extraction still isn't happening, check for a processing queue backlog. Large libraries can cause OCR jobs to queue. You can manually trigger re-processing by opening the file, going to the file's property panel, and selecting Run OCR if that option is present. Alternatively, move the file out of the library and back in, re-upload triggers a fresh OCR job.
Files larger than 20 MB may not process reliably through OCR. Split oversized scanned documents before uploading. Also confirm the document library isn't in a site collection that has information management policies blocking content analysis, check under Site settings > Site collection administration > Information management policy settings.
These two services have their own specific failure modes that are distinct from the general model and OCR issues above.
eSignature problems almost always come down to one of three things: the feature isn't enabled for the tenant, the document isn't stored in a SharePoint library that eSignature has been enabled on, or the recipient email address doesn't meet the service's requirements. To check tenant-level enablement, go back to your SharePoint admin center document processing settings and confirm eSignature is toggled on. For library-level enablement, go to Library settings > eSignature and verify it's active. Recipients must have valid email addresses, shared mailboxes and distribution lists often fail silently here. Use individual mailbox addresses for testing.
If eSignature requests are sending but the signed document isn't appearing back in SharePoint, check that the SharePoint site's storage quota isn't full. eSignature writes the completed document back to the originating library, and if there's no space, the write silently fails. Go to SharePoint admin center > Active sites, find your site, and check the Storage column.
Document translation failures are usually either unsupported language pairs or file format mismatches. Microsoft 365 document translation supports over 70 languages, but the availability of specific dialect combinations can vary. If you're attempting to translate to or from a less common language and getting an error, check the officially supported language list in the Microsoft documentation. For file formats, translation works on Word documents (.docx), PowerPoint files (.pptx), PDF files, and several other formats, but it won't process files that are checked out to another user or that are locked by an active co-authoring session. Close all co-authors and check the file in before attempting translation.
Connect-PnPOnline -Url https://[yourtenant].sharepoint.com/sites/[yoursite] -Interactive
Get-PnPSite | Select-Object StorageUsage, StorageMaximumLevelAfter a translation job completes successfully, you'll find a new file in the same library with the target language code appended to the filename, for example, Contract_es.docx for a Spanish translation of Contract.docx. The original file is untouched. If you don't see the translated file after 5 minutes, the job failed, check the library's version history on the original file for any processing notes.
Advanced Troubleshooting
If you've gone through all five steps above and document processing is still broken, you're dealing with either an enterprise configuration issue, a tenant-level policy conflict, or something that genuinely requires Microsoft's involvement. Here's where to look.
Check the Microsoft 365 Service Health Dashboard
Before assuming your configuration is wrong, rule out a service incident. Go to admin.microsoft.com, then Health > Service health. Filter by SharePoint Online and look for any active advisories or incidents tagged with "Document processing" or "Syntex" (Microsoft sometimes still uses the old name in service health messages). If there's an active incident, your fix options are limited, wait it out.
Event Viewer and ULS Log Analysis for On-Premises Hybrid
If you're running a SharePoint hybrid environment where on-premises SharePoint connects to Microsoft 365 document processing, check the ULS logs on your on-premises SharePoint servers. The relevant log category is Syntex Document Processing. Use the following PowerShell to filter ULS logs for document processing errors:
Merge-SPLogFile -Path "C:\ULS\DocProcessing.log" -Overwrite -Area "Syntex" -Level High
Get-Content "C:\ULS\DocProcessing.log" | Select-String "error|exception|failed" -iGroup Policy and Conditional Access Conflicts
In organizations with strict Conditional Access policies, document processing service calls can be blocked if the AI Builder service principal isn't included in your policy exclusions. The service principal you need to whitelist is AI Builder (App ID: ad40333e-9910-4b61-b281-e3aeeb8c3ef3). In Azure Active Directory, go to Security > Conditional Access > Named locations and verify that Microsoft's AI service endpoints aren't being blocked by network or access policies.
Power Platform Environment Mismatches
Structured and freeform document processing models run inside Power Platform environments. If your SharePoint admin center points to one Power Platform environment but your models were built in a different environment, the models won't apply. Go to the SharePoint admin center, then Settings > Document processing, and look for the Power Platform environment setting. Confirm it matches the environment where your AI Builder models live. You can set a custom environment here, see the official documentation on setting up a custom Power Platform environment if you need models separated across business units.
Per-User License Expiry Edge Cases
If you're still on per-user licenses and they're about to expire, note the exact capabilities that will stop working: applying unstructured models to libraries, creating prebuilt, structured, and freeform models, uploading to libraries with applied models, and running models on demand. Content assembly, taxonomy services, content query, annotations, and document library rules will also stop. Plan your transition to pay-as-you-go before the licenses expire, don't wait until things break to set up billing, because the Azure billing propagation delay means you'll have a gap in service even after you configure it correctly.
Prevention & Best Practices
Most document processing outages I've seen in production environments were preventable. The pattern is almost always the same: someone set everything up once, it worked, and then months later a license expired, an Azure subscription got moved to a different billing account, or a new Conditional Access policy got rolled out that nobody thought would affect SharePoint. The fix is systematic monitoring and a little proactive housekeeping.
First, set up an Azure cost alert on the resource group you linked to document processing billing. This serves double duty: it catches unexpected cost spikes from runaway processing jobs, and it also tells you when usage drops to zero unexpectedly, which is a reliable signal that something in the processing chain has broken. A zero-usage alert should trigger an investigation immediately rather than waiting for a user complaint.
Second, document your environment configuration in a shared IT runbook. Write down the Azure subscription ID, the resource group name, the region, the Power Platform environment linked to document processing, and the date your per-user licenses expire (if you still have them). This information is surprisingly hard to reconstruct under pressure when something breaks at 4pm on a Friday.
Third, run a monthly smoke test. Pick one library with a model applied, upload a test document, and verify the model processes it correctly. This takes two minutes and catches silent failures before they become business-critical incidents. The most expensive document processing outages I've seen were ones that had actually been broken for weeks, nobody noticed until an important deadline made the failed processing visible.
Finally, stay ahead of the AI Builder credits transition. Microsoft announced in October 2025 that AI Builder credits are being progressively ended. If any of your document processing workflows were built on AI Builder credits rather than the pay-as-you-go billing meter, those workflows need to be migrated. Don't wait for the credits to run out, audit your Power Platform environments now and confirm which models are billing through which mechanism.
- Set an Azure budget alert at 80% of expected monthly document processing spend, catches runaway jobs before they become expensive
- Create a dedicated resource group for document processing billing so costs are isolated and easy to audit
- Assign the SharePoint Admin role to at least two people, single-admin tenants create unnecessary risk when billing configuration needs to change urgently
- Test eSignature and OCR with a dummy document immediately after any tenant-level Conditional Access policy change, these services are the first to break when network policies shift
Frequently Asked Questions
Why can't I find "Microsoft Syntex" in the admin center anymore?
Microsoft officially retired the Syntex brand name. The same features and services now live under the name "Document processing for Microsoft 365" in the SharePoint admin center under Settings. All the functionality is identical, only the label changed. Any guides or bookmarks referencing "Syntex" in the admin navigation are outdated, but if you know where to look, everything is still there under the new name.
My document processing billing is set up but I'm not being charged, is something wrong?
Not necessarily. Through December 2025, Microsoft included a monthly free capacity allocation for organizations with pay-as-you-go billing configured, letting you test services without cost. If you're still within that free tier, or if your usage genuinely hasn't exceeded the included capacity, your bill will be zero. Check the Azure Cost Management blade for your document processing resource group, if you see meters appearing with zero usage, that means the connection is working but you haven't exceeded the free allocation. Once you do exceed it, billing kicks in automatically.
Can I use document processing on a Government Community Cloud (GCC) tenant?
GCC tenants are in a different position from commercial tenants. Pay-as-you-go licensing, which is required for all document processing services, is not yet available for GCC. If you're on a GCC tenant, you can continue using per-user licenses for as long as they remain valid. The moment those licenses expire, however, you'll lose access to document processing features until Microsoft makes pay-as-you-go available in the GCC environment. There's no workaround for this; it's a platform availability gap, not a configuration issue.
My structured model was working fine for months and suddenly stopped extracting fields, what happened?
A few things can cause this. If your per-user licenses recently expired and you haven't fully transitioned to pay-as-you-go, model processing stops. If the Power Platform environment linked to your SharePoint tenant changed, for example, someone recreated the default environment or moved to a custom environment, the model loses its execution context. Check your Power Platform environment mapping in the SharePoint admin center under Settings > Document processing. Also verify in the Azure portal that the AI Builder resource provider is still active and that no new Conditional Access policy was applied to your tenant that's blocking the AI Builder service principal.
How much does document processing actually cost per document?
Pricing varies by service and Microsoft updates rates periodically, so the most accurate current figures are in the official pay-as-you-go pricing page for document processing in the Microsoft documentation. As a general framework: services are billed per transaction, per page for OCR, per document for translation, per model run for structured and freeform processing. Microsoft also provides a SharePoint cost calculator tool (linked from the official pricing page) that lets you input your expected volume and see estimated monthly costs before you commit. Running that calculator against your actual document volumes before enabling services is genuinely useful for budget planning.
Can any user in my organization use document processing, or do they need a special license?
Under the pay-as-you-go model, any user in your tenant with a valid Microsoft 365 license can use document processing services, there's no per-seat addon required for end users. The billing happens at the organizational level through the Azure subscription, not per user. The key requirement is that pay-as-you-go billing is configured at the tenant level by an admin, and the specific services the user needs are enabled. A user who wants to run OCR on documents in their SharePoint library doesn't need any special license, they just need OCR to be enabled on that library by a site owner or admin.