Your SharePoint library looks organized. Retention labels are applied. Your compliance team assumes the metadata framework will hold up under scrutiny.
Then the auditor asks to see your disposal log, and you realize you've been tracking the wrong fields for three years.
SharePoint metadata mistakes don't announce themselves. They accumulate quietly until a legal hold, regulatory audit, or disposition cycle exposes the gaps. The problem isn't that teams ignore metadata, it's that they configure it without understanding what compliance actually requires.
Why These Mistakes Keep Happening
SharePoint offers hundreds of metadata options. The Victorian government's recordkeeping standard asks for six essential elements: Agent, Date, Identifier, Protective Marking, Disposal, and Description. Your IT team sees SharePoint's "out of the box" columns and assumes they're compliant by default.
They're not. SharePoint provides the raw materials, but you still need to map them to your jurisdiction's requirements. Most teams skip this mapping step and discover the mismatch only when they need to prove defensible disposition or respond to a data subject access request.
Mistake 1: Using Local Library Columns Instead of Site Columns
Why it happens: You need a "Document Type" field for one library, so you create it directly in Library Settings. It's fast, it works, and you move on.
The consequence: That column exists only in that library. When you need to run a disposition report across ten libraries, you discover you've created ten different "Document Type" columns with inconsistent values. Your PowerShell script can't aggregate them. Your retention schedule can't reference them consistently.
The fix: Create all custom metadata at the Site Columns level (via Site Settings, not Library Settings). Add them to libraries through content types or by selecting "Add from existing site columns." This makes the field reusable, queryable across sites, and manageable from a central location. If you've already created local columns, you'll need to recreate them as site columns and migrate the values. SharePoint won't do this conversion for you.
Mistake 2: Ignoring the Difference Between 'Modified' and 'Created_x0020_Date'
Why it happens: You see "Created" and "Modified" in your library view and assume those timestamps are your audit trail. They display in a readable format, so they must be the authoritative dates.
The consequence: When you extract metadata via PowerShell for a disposition authority submission, you discover SharePoint stores multiple date fields: Created, Created_x0020_Date, Modified, and version-specific timestamps. The "Created" field shown in views uses your local time zone. The Created_x0020_Date field stores UTC timestamps. If your retention schedule triggers on creation date and you're using the wrong field, your cutoff calculations are wrong.
The fix: Document which date fields your organization uses for compliance purposes. For most recordkeeping requirements, Created and Modified (the human-readable FieldValues) meet the "Date" metadata requirement. But if you're scripting disposition or audit exports, verify that your PowerShell commands extract the correct timestamp format. Test your scripts against items created in different time zones before you rely on them for a disposal run.
Mistake 3: Treating Managed Metadata Terms as Simple Text
Why it happens: You configure a "Classification" column using the Managed Metadata Service. In the SharePoint interface, users select "Finance - Budget Documents" from a term set, and it displays correctly.
The consequence: When you export to Excel or extract via PowerShell, the Classification column shows Microsoft.SharePoint.Client.[Taxonomy](/glossary/taxonomy).TaxonomyFieldValue instead of the actual term. Your disposal report lists 400 items with no readable classification. You can't sort, filter, or report on the values without additional scripting.
The fix: If you're using managed metadata columns (term sets), your extraction scripts must include .Label to retrieve the human-readable term. For example: $Item.FieldValues["Classification"].Label. Test this before you build reports that executives or auditors will see. If you're exporting to Excel from a view, add the managed metadata column to the view first, it will display the label, not the underlying object reference.
Mistake 4: Assuming Document ID Meets Your Identifier Requirement
Why it happens: You enable Document IDs at the site collection level. SharePoint generates unique identifiers like LEGAL-1563464234-215. You assume this satisfies the "Identifier" metadata requirement.
The consequence: Document IDs work well for human reference, but they're not immutable. If you move a document to a different site collection, the Document ID can change or break. For disposition purposes or long-term archival, you need a truly persistent identifier. The UniqueId field (a GUID like 69fd0215-1e88-47f1-b67b-863e07511ec2) is immutable, but it's not human-readable and doesn't appear in standard views.
The fix: Decide whether your use case requires human readability or immutability. For internal workflows and legal hold tracking, Document IDs are sufficient. For accessioning to an archival system or creating a permanent disposition log, extract the UniqueId field via PowerShell and store it alongside the Document ID. Your Records Control Schedule should specify which identifier you're using as the authoritative record reference.
Mistake 5: Failing to Extract Retention Label Metadata Before Disposition
Why it happens: You apply retention labels through Microsoft Purview. SharePoint displays them in the library view. When the retention period expires, the system deletes the items automatically, and you assume you're compliant.
The consequence: Your Records Disposition Authority requires proof of what was destroyed, when, and under which schedule. The retention label metadata (_ComplianceTag) is stored with the item, when the item is deleted, so is the label. You have no audit trail.
The fix: Before any automated disposition cycle runs, extract the metadata for items eligible for destruction. Your PowerShell script should capture Name, _ComplianceTag (retention label), Created, Modified, UniqueId, and any custom classification fields. Export this to a CSV and store it outside SharePoint as your disposition log. Schedule this extraction to run before the disposition window opens, not after.
Prevention Checklist
Before you finalize your SharePoint metadata configuration:
- Map your jurisdiction's required metadata elements to specific SharePoint columns (don't assume "out of the box" columns meet the requirement without verification)
- Create all custom metadata as Site Columns, never as local library columns
- Document which date fields you're using for retention triggers and verify time zone handling
- Test managed metadata extraction in both Excel exports and PowerShell scripts
- Choose between Document ID and UniqueId based on your immutability requirements
- Build a pre-disposition metadata extraction script and test it on a sample library
- Run a full metadata export on one library and review every column to confirm you're capturing what auditors will ask for
- Verify that your retention labels are visible in the
_ComplianceTagfield when extracted via PowerShell
Your metadata framework either proves your compliance or exposes your gaps. Configure it with the audit in mind, not just the user interface.
