Fix Microsoft 365 Document Processing Issues (2026)
Why This Is Happening
I've seen this scenario play out more times than I can count: an IT admin sets up Microsoft 365 document processing, walks through the SharePoint admin center, thinks everything looks right , and then a user tries to run an OCR scan or kick off a document translation and absolutely nothing happens. No error. No output. Just silence. Sometimes there's a cryptic message like "This feature is not available" or "Service not configured." It's maddening.
Here's the real story. Microsoft 365 document processing , the suite of AI-powered content services that used to live under the Microsoft Syntex brand, moved to a pay-as-you-go model billed through Azure. That transition caught a lot of organizations off guard. If your Azure subscription isn't correctly linked to your Microsoft 365 tenant, or if pay-as-you-go billing hasn't been activated in the SharePoint admin center, every single one of these services goes dark. Autofill columns won't populate. The eSignature request button won't appear. Document translation produces nothing. And the error messages Microsoft gives you rarely point to billing as the cause.
There's also the matter of the October 2025 announcement about AI Builder credits. Microsoft ended the AI Builder credits program progressively, which means any organization that was relying on those credits to fund document processing workloads had to pivot to pure pay-as-you-go billing. If you haven't made that switch yet, or if someone in your org set up billing back in 2024 but the Azure subscription has since lapsed, the services just stop working without warning.
Beyond billing, there are several other root causes I see regularly with Microsoft 365 document processing worldwide deployments: SharePoint site permissions not including the right service account, the document library not having a model applied to it, models being created but never published, and, this one trips up admins constantly, users having a Microsoft 365 license but that license not granting them access to use the AI services without the pay-as-you-go backend being active.
Government Community Cloud (GCC) organizations hit a completely separate wall: pay-as-you-go licensing isn't available for GCC environments yet. If you're in that bucket, you need to keep per-user licenses assigned until Microsoft rolls out PAYG for GCC. Trying to set up Azure billing on a GCC tenant will either fail silently or produce confusing errors in the admin portal.
The good news is that once you understand why this breaks, fixing it is methodical. I know this is frustrating, especially when it blocks actual business workflows like contract signing or invoice processing. Let's work through it. Browse all Microsoft fix guides →
The Quick Fix, Try This First
Before you go digging through Azure subscriptions and SharePoint model libraries, run through this single check first. In about 70% of cases where Microsoft 365 document processing stops working without any changes being made, the root cause is that pay-as-you-go billing either was never set up or has become disconnected from the tenant. This is a five-minute check that can save you two hours of deeper troubleshooting.
Sign in to the Microsoft 365 admin center at admin.microsoft.com with a Global Administrator or SharePoint Administrator account. From the left navigation, go to Settings > Org settings > Services. Scroll down and click SharePoint. In the panel that appears, look for the Document processing section. You'll see either a green confirmation that pay-as-you-go is connected to an Azure subscription, or you'll see a yellow warning or empty state indicating it isn't configured.
If billing is disconnected or missing, here's what to do right now:
- Open the SharePoint admin center at
[yourtenant]-admin.sharepoint.com - In the left menu, click Settings
- Click Pay-as-you-go (it may appear as Billing in some tenants)
- Click Set up pay-as-you-go billing
- Select your active Azure subscription from the dropdown, this must be a subscription with an active payment method and no spending cap set to zero
- Select the Azure resource group where billing meters should be created
- Click Save
After saving, wait about 5–10 minutes before testing any document processing service. The provisioning propagates across the Microsoft 365 services backend and isn't instant. Then go to a SharePoint document library, upload a test file, and try running whichever service was failing, OCR, document translation, autofill columns, or another.
ReadOnly or CanNotDelete lock on the resource group will silently block Microsoft from creating the billing meters, and the SharePoint admin center won't tell you this explicitly. Check Azure Portal > Subscriptions > [your sub] > Locks before saving your billing config.
This is the foundation. Without a properly linked Azure subscription, Microsoft 365 document processing services won't run, full stop. Even if users have valid Microsoft 365 licenses, the AI services that power document processing require Azure-based billing meters to be active and healthy.
Start in the Azure Portal at portal.azure.com. Navigate to Subscriptions in the left sidebar. Find the subscription you intend to use for document processing billing. Check three things:
- Status: Must show Active. If it shows Disabled, Deleted, or Past Due, fix the subscription health before anything else.
- Spending limit: Enterprise Agreement subscriptions sometimes have a $0 spending cap. Navigate to Cost Management > Budgets and confirm no budget alert is blocking new spend.
- Resource providers: Go to Settings > Resource providers within the subscription and search for
Microsoft.SharePoint. The status must say Registered. If it shows NotRegistered, click it and hit Register.
Once the subscription looks healthy, go back to the SharePoint admin center, navigate to Settings > Pay-as-you-go, and connect that subscription. The Azure region selected for billing should ideally match your Microsoft 365 tenant region for latency and compliance reasons, this matters especially for O365 worldwide deployments spread across multiple geographies.
If the connection succeeds, you'll see a confirmation banner in the SharePoint admin center and the document processing services will appear as Available in the service list. If you see an error code here, note it exactly, common ones include AzureSubscriptionNotFound and BillingAccountNotLinked, both of which point back to the subscription health issues above.
Connecting your Azure subscription activates the billing backend, but that's not the same as turning the services on for your users. Each document processing service, autofill columns, document translation, eSignature, optical character recognition, content assembly, image tagging, taxonomy tagging, and the model types, needs to be explicitly enabled in the SharePoint admin center.
Head to SharePoint admin center > Settings > Document processing. You'll see a list of all available services with toggle switches next to each one. By default, some may be off. Enable the ones your organization needs. Pay attention to these in particular:
- Optical character recognition (OCR): Required if users need to search for text within scanned PDFs or image files in SharePoint libraries.
- Autofill columns: This one uses large language models to automatically extract or generate metadata for files, it requires pay-as-you-go to be active and will fail silently if billing isn't set up.
- eSignature: Needs to be enabled here before any user can send a signature request from a SharePoint library. The button simply won't appear in the library ribbon if this service isn't on.
- Document translation: Must be toggled on before users can right-click a file in a library and select the translation option.
After enabling services, give it about 15 minutes before testing. The service availability propagates to SharePoint sites progressively. If you test immediately after enabling and still see missing options, that's likely just propagation lag, not a persistent error. Open an InPrivate/incognito browser window to rule out cached UI state when you test, the SharePoint interface caches permission and service state aggressively.
Even with billing active and services enabled tenant-wide, individual users can still be blocked from using Microsoft 365 document processing if their permissions at the site or library level aren't configured correctly. This is one of the most common "it works for me but not for them" complaints I hear from SharePoint admins.
For most document processing features, including running OCR, triggering autofill columns, and requesting eSignatures, users need at minimum Contribute permissions on the SharePoint document library. Read-only access is not sufficient. Here's how to verify:
- Navigate to the SharePoint document library where the issue occurs
- Click the gear icon (Settings) in the top right > Library settings
- Under Permissions and Management, click Permissions for this document library
- Find the affected user or group and confirm their permission level shows Contribute, Edit, or Full Control
For users who need to create or manage document processing models, the unstructured, structured, freeform, or prebuilt model types, they need to be a Site Owner or have been explicitly granted model management rights. Regular contributors can use models once applied, but they can't configure or publish them.
Also confirm that the user's Microsoft 365 license is active. Navigate to Microsoft 365 admin center > Users > Active users, find the user, click their name, and under the Licenses and apps tab, confirm they have an active Microsoft 365 license assigned. The specific tier (E3, E5, Business Premium, etc.) doesn't gate access to pay-as-you-go services, any active Microsoft 365 license qualifies a user to use these services once pay-as-you-go is set up at the tenant level. But an expired or unassigned license will block them entirely.
A lot of confusion around Microsoft 365 document processing centers on the difference between creating a model and actually putting it to work on a library. You can build a beautifully trained prebuilt model for invoice extraction, but if you never publish it to a library, it does absolutely nothing. I've debugged "broken" setups where the model existed, was trained, but was just sitting in a content center with no library associations.
Here's the full flow for getting a model working:
- Go to your SharePoint content center (if you don't have one, you can create a site using the Content Center template from the SharePoint admin center under Active sites > Create > Content center)
- Click New > Model and choose your model type, prebuilt (for invoices, contracts, receipts), structured/freeform (for forms with consistent layouts), or unstructured (for varied documents)
- Follow the training wizard: for prebuilt models, you select the entity extractor type (e.g., Invoice model); for structured/freeform, you upload sample documents and label fields; for unstructured, you upload examples and create classifiers
- Once trained, click Publish, this is the step people skip
- After publishing, navigate to your target SharePoint document library, go to Automate > Apply a document understanding model, and select your published model
Once applied, the model will process new files uploaded to that library and run on existing files if you trigger an on-demand run. To trigger on-demand: go to the library, select the files, and click Automate > Run model from the command bar. If the Automate menu isn't showing, the model hasn't been successfully applied, go back and repeat the apply step.
These three services are the ones I get the most specific error reports about, so let's tackle them individually since each has its own failure mode.
Optical Character Recognition (OCR) not working: OCR in SharePoint scans images and image-based PDFs so their text becomes searchable. If OCR results aren't appearing, first confirm the service is enabled (Step 2 above). Then check the file type, OCR supports JPEG, PNG, TIFF, BMP, and PDF formats. Files over 500 pages or 20 MB may hit processing limits. If the file is within limits and OCR is enabled, try removing the file from the library and re-uploading it; OCR processing triggers on upload events. If it still doesn't run, check the ULS logs via the SharePoint admin center or look in the Microsoft 365 service health dashboard under Health > Service health for any active OCR incidents.
eSignature button missing or requests failing: The Send for eSignature option appears in the document library command bar only when eSignature is enabled and the file is a supported format (PDF is the primary supported format for signing). If the button is missing for a specific user, check that they have at least Contribute access (Step 3). If the button appears but the request fails after submission, the most common cause is an expired or misconfigured Azure billing setup, a failed meter charge will cause the request to be silently dropped.
Document translation producing no output: When a user right-clicks a file and selects Translate, a translated copy should appear in the same library within minutes. If nothing appears, check that the source document is a supported format (DOCX, PPTX, XLSX, PDF, TXT, HTML, and several others). Files containing only images without embedded text won't translate because there's no text layer to process. Also confirm that the target language selected is one of Microsoft's supported translation languages, the list is extensive but not unlimited. If the file format and language are both supported and translation still fails, re-verify billing connectivity; the document translation service meter is charged per page and a billing error halts processing mid-queue.
# PowerShell: Check SharePoint service health via Graph API
# Requires Microsoft.Graph module and appropriate permissions
Connect-MgGraph -Scopes "ServiceHealth.Read.All"
Get-MgServiceAnnouncementHealthOverview | Where-Object {$_.Service -like "*SharePoint*"} | Select-Object Service, StatusAdvanced Troubleshooting
If the five steps above haven't resolved your Microsoft 365 document processing issues, you're likely dealing with a tenant-level configuration conflict, a Group Policy or Conditional Access restriction, or an enterprise network issue. These are less common but they do happen, especially in large organizations with complex governance setups.
Check the Unified Audit Log for Document Processing Events: In the Microsoft Purview compliance portal at compliance.microsoft.com, navigate to Audit > New search. Filter activities by searching for "Syntex" or "document processing", the underlying audit event names still reference the Syntex service name in many cases. Set a date range covering when failures started. Look for events with ResultStatus: Failed or unusual OperationType entries. These logs are often the fastest path to understanding what's actually going wrong at the service layer.
Group Policy and Conditional Access Conflicts: In enterprise environments with Conditional Access policies, the Microsoft 365 document processing services make background calls to Azure AI endpoints. If your Conditional Access policies require compliant devices or block access from service accounts, those background calls can fail silently. Check Azure Active Directory > Security > Conditional Access > Sign-in logs and filter for failures from SharePoint or Syntex service principal names. If you see blocks, you may need to create a named location or service exclusion for the document processing service principals.
Custom Power Platform Environments: Organizations running structured or freeform document processing models in a custom Power Platform environment have an extra configuration layer. According to the official documentation, you need to specifically configure the custom Power Platform environment for document processing, the default environment setup doesn't automatically carry over. Go to Power Platform admin center > Environments > [your environment] > Settings > Features and confirm that AI Builder features are enabled in that environment. If your organization is affected by the end-of-AI-Builder-credits announcement (October 2025), verify that you've transitioned those workloads to pay-as-you-go billing as well.
Event Viewer for On-Premises Hybrid Scenarios: If your SharePoint environment is hybrid (on-premises + cloud), open Event Viewer on your SharePoint server, navigate to Applications and Services Logs > Microsoft > SharePoint > Operational, and filter for Event IDs in the 8xxx range, which cover search and content processing errors. Event ID 8001 and 8011 commonly appear when hybrid configuration breaks the connection between on-premises SharePoint and the Microsoft 365 document processing services in the cloud.
Tenant-Level Throttling: High-volume document processing workloads, especially OCR or translation jobs kicked off against thousands of files simultaneously, can trigger throttling at the Microsoft service layer. If you see errors appearing intermittently and only during bulk operations, space out your processing jobs. The on-demand model run in SharePoint processes files in queue and will handle throttling automatically if triggered from the UI, but custom Power Automate flows calling document processing directly can hit HTTP 429 errors. Implement exponential backoff in any custom flow that triggers these services.
If you've confirmed billing is active, services are enabled, permissions are correct, and models are published, and document processing still isn't working, it's time to escalate. Open a support ticket via the Microsoft 365 admin center > Support > New service request. Be specific: include your tenant ID (found at Azure Active Directory > Overview), the specific service that's failing, the exact error message or behavior, and the timeframe when it started failing. Microsoft's Syntex/document processing support team can check backend telemetry that you simply can't access. You can also post in the Tech Community forums at Microsoft Support, the product team monitors those threads and has resolved several known bugs there first.
Prevention & Best Practices
Once you've got Microsoft 365 document processing running correctly, you want to keep it running correctly. The most painful document processing outages I've seen were entirely preventable, they happened because no one was watching the billing meters, or a routine Azure subscription change quietly broke the tenant connection.
Set up Azure Cost Management alerts for your document processing billing meters. In the Azure Portal, go to Cost Management + Billing > Budgets and create a budget scoped to the resource group you designated for SharePoint billing. Set an alert at 80% of your expected monthly spend. This way, if usage spikes unexpectedly, say, someone accidentally triggers OCR on an entire file archive, you'll know before the bill surprises you, not after.
Document your service configuration. It sounds basic, but organizations that have a simple runbook documenting which Azure subscription is linked, which services are enabled, and which content centers own which models recover from admin turnover or accidental misconfiguration in minutes rather than hours. Keep that doc in SharePoint, the irony of using SharePoint to document your SharePoint document processing setup is not lost on me, but it works.
For per-user licenses that are still active: remember that while existing per-user licenses can still be assigned to new users, they're no longer available for purchase. Plan your transition to pay-as-you-go now, before those licenses expire, rather than scrambling after an unexpected expiration event. Once a per-user license expires, services stop immediately, there's no grace period for document processing.
Test your document processing models regularly, not just when something breaks. Build a monthly health check into your SharePoint admin routine: upload a known test document to each library that has a model applied, confirm that the model extracts the expected fields or classifies the document correctly, and verify that the output columns are populated. Models can drift in accuracy if the document formats they're processing change over time, and catching that early prevents a backlog of incorrectly processed files.
- Set Azure Cost Management budget alerts for your SharePoint billing resource group at 80% of expected monthly spend
- Create a runbook documenting your Azure subscription link, enabled services, and content center model inventory, review it quarterly
- Plan your per-user license to pay-as-you-go migration before licenses expire, check expiry dates in Microsoft 365 admin center under Billing > Licenses
- Run a monthly model health check: upload test files, verify extraction results, confirm output columns populate correctly in the target library
Frequently Asked Questions
Why did my Microsoft 365 document processing stop working overnight without any changes?
The most common cause of an overnight failure is an Azure subscription event, an expired payment method, a subscription moving to a disabled state, or a spending limit being hit. Microsoft's document processing services check billing health continuously, and if the Azure subscription becomes unhealthy, services suspend. Head to Azure Portal > Subscriptions and check the status. Also check the Microsoft 365 service health dashboard at admin.microsoft.com > Health > Service health, Microsoft occasionally has service incidents that affect document processing across all O365 worldwide regions simultaneously, and you'll see a posted incident there if that's the case.
Can regular users run document processing, or does it require an admin account?
Regular users with any active Microsoft 365 license can use document processing services, they don't need admin rights. The key requirements are that pay-as-you-go billing is active at the tenant level (which an admin sets up), and the user has at least Contribute permission on the SharePoint library where they're trying to use the service. Admin rights are only needed to configure services, create and publish models, or change billing settings. For day-to-day use like translating a document, requesting an eSignature, or having autofill columns populate metadata, a standard user account is completely sufficient.
How much does Microsoft 365 document processing actually cost per document?
Pricing is per-transaction and varies by service. Microsoft publishes the rates on the SharePoint cost calculator tool, which lets you model your expected costs based on estimated usage volumes. OCR is priced per page, document translation is priced per page translated, eSignature is priced per signing request, and AI model processing (prebuilt, structured, freeform, unstructured) is priced per processed file or page depending on the model type. The billing appears as service meters in your Azure subscription under the SharePoint resource group you designated. I'd recommend running the cost calculator before enabling high-volume workloads, processing a million-page document archive will add up quickly if you haven't modeled it first.
Why can't I find the "Apply a document understanding model" option in my SharePoint library?
There are three common reasons this option is missing from your library's Automate menu. First, you might not have Site Owner permissions on that site, this option is restricted to site owners and above. Second, the document processing services may not be enabled in your tenant's SharePoint admin center under Settings > Document processing. Third, there may be no published models in your content center, if you created and trained a model but never clicked Publish, it won't appear as an option to apply. Check all three in that order. If you're certain permissions and services are correct but the option still doesn't appear, try the SharePoint admin center page and confirm the content center is correctly provisioned under Active sites.
Does Microsoft 365 document processing work for GCC (Government Community Cloud) tenants?
Not yet, as of the official documentation. Pay-as-you-go licensing, and the AI-powered document processing services that depend on it, aren't currently available for Government Community Cloud organizations. GCC tenants can continue using per-user licenses to access document processing features, but per-user licenses for these services are no longer sold to new customers. If you're a GCC organization, keep existing per-user licenses active and assign them to users who need document processing access. Microsoft hasn't announced a specific date for GCC pay-as-you-go availability, so monitor the Microsoft 365 roadmap at microsoft.com/en-us/microsoft-365/roadmap for updates.
What happened to Microsoft Syntex, is it the same as document processing now?
Yes, functionally identical. Microsoft rebranded the pay-as-you-go services that were offered under the Microsoft Syntex name to "document processing services for Microsoft 365." The official documentation is explicit that the features and functionality remain unchanged, only the name changed. If you see references to Syntex in older documentation, support articles, PowerShell cmdlets (like Set-SPOTenant -EnableSyntexAutomation), or Azure billing entries, those still apply to the same services now called document processing. The product team has been gradual about updating all references, so you'll continue to see "Syntex" appear in various places in the admin center, audit logs, and API responses for the foreseeable future.