What is Microsoft Syntex, and can it do contract work?

Syntex is Microsoft's document understanding layer for SharePoint: you teach it to read a document type, and it classifies files and extracts fields from them where they already live. It handles contracts well as documents. It has no view of what your ERP recorded from those contracts, and that gap is the whole of the contract problem.

Does Microsoft Syntex still exist?

The capability does. The name has moved twice, which is most of why this question gets typed at all.

It launched as SharePoint Syntex, became Microsoft Syntex, and Microsoft has since folded the content services into SharePoint Premium. The Microsoft Learn service description for SharePoint Syntex now points readers to the Microsoft Syntex features page, and the SharePoint Premium announcement describes it as the next evolution of the same services.

If you are searching for Syntex because someone recommended it a year ago, you are not looking for a retired product. You are looking for a renamed one. The models, the content centers and the extraction all survived the rename.

What does it actually do?

Four things, and Microsoft is specific about the machinery behind each.

Document understanding. You teach it by example rather than by code. Microsoft's own description is that these models "are based on Language Understanding models in Azure Cognitive Services," created and managed in a Syntex content center, and publishable to any library. This is the part that reads a document and decides what kind of document it is.

Form processing. A separate engine "based on AI Builder" that "automatically recognizes and extracts common values from semi-structured or structured documents such as dates, figures, names, or addresses." Microsoft notes these models "are built without code and require only a few documents for reliable results."

Object recognition. Image tagging against a visual dictionary, and conversion of handwritten text into tags.

Graph connectors. Indexing of remote repositories — file shares, Azure SQL, and non-Microsoft sources including Box and IBM FileNet — into Microsoft Graph so they are searchable across Microsoft 365. Microsoft counts more than 130 connector sources available from itself or its partners.

Read that list as an engineer and the shape is clear. It is a classification and extraction layer that operates on files, in the place the files are stored, and writes what it finds back as metadata.

So can it read a contract?

Yes, and reasonably well for what it is built to do.

A contract is a semi-structured document. Form processing is explicitly aimed at pulling dates, figures, names and addresses out of exactly that. Point it at a folder of signed agreements and you can get a library where every file carries an effective date, a counterparty, a value and a notice period as real columns rather than as text buried in a PDF.

That is genuinely useful, and it is more than most organisations have. If your contracts are currently a SharePoint folder nobody queries, this converts them into something a person can filter and a workflow can act on.

Where does it stop?

It stops at the library.

Syntex knows what your contract says, once you have taught it to look. It does not know what your ERP recorded. Those are two different facts, and the distance between them is where contract money actually goes.

Consider the renewal case. Business Central holds real fields for this: the vendor subscription contract documentation names Cancellation possible until and Term until among the fields on a subscription line. Those fields are on the record. The clause that should fill them is in a document. Syntex can read the clause. It cannot tell you that the field on the record disagrees with it, because the record is not in its world.

The same holds for price. A negotiated rate sits in the agreement; a different rate sits on the purchase line that bills. Extraction gives you the first. It says nothing about the second, and nothing about the fact that they no longer match.

What is it not?

Three things it is not, said plainly, because the alternative is a buyer discovering them after deployment.

It is not contract review against a playbook. Extraction pulls values out. Review compares a clause against your position, your fallback and your red line, then proposes replacement language. Those are different jobs with different inputs — the second needs your standards as an input, and Syntex takes documents, not standards.

It is not a reconciliation layer. Nothing in the feature list compares an extracted value against a system of record. That comparison is a separate build, and it needs read access to the ERP.

It is not a decision. It produces metadata. What to do when the metadata and the record disagree is still a question for a person or for something built to answer it.

Where does it fit, then?

As the front half of a pipeline, and it is a good front half.

If the documents are in SharePoint, Syntex is the natural way to classify them and lift the fields out, using licensing you may already hold and models your own team can teach. It is Microsoft-native, it runs where the files are, and it requires no new repository.

What it hands you is a structured view of what the documents say. The second half — checking that view against what Dynamics 365 recorded, and raising the difference — is the work that changes an outcome. Cognilium AI builds that second half as AI optimization apps for Microsoft Dynamics 365: the apps read the ERP live, compare it to the agreement, and prepare the correction for a person to approve.

Using both is the sensible answer for a Microsoft shop. Use Syntex or SharePoint Premium for what it is good at, and put the comparison somewhere that can see both sides.

Sources

• SharePoint Syntex features — Service Descriptions, Microsoft Learn · ms.date 2024-10-04
• Vendor subscription contracts — Business Central, Microsoft Learn · ms.date 2026-05-04