Mercury xRM sits on Microsoft Dynamics 365, and its CV parsing feeds candidate records that your whole agency works from. When parsing fails, bad data flows straight into Dynamics — empty name fields, merged contact details, missing roles. This guide shows you how to trace and fix the common failures.
TL;DR: Mercury xRM parsing errors come from tables in the CV header, graphics, merged contact lines, and inconsistent dates. Clean the CV before upload: single column, plain text contact block, one date format, text-based .docx. Distill automates the cleanup at volume.
Quick diagnosis: why Mercury xRM parsing fails
| Symptom | Likely cause | Quick check |
|---|---|---|
| Candidate name not extracted | Name inside a header table | Is the name in a table or graphic? |
| Contact details merged/missing | Phone + email share a line or symbol | Are they on separate lines? |
| Roles skipped or misdated | Inconsistent date formats | Do all roles use the same date style? |
| Record fields misaligned | Tables in the experience block | Is work history laid out in a table? |
| Record created but fields empty | Scanned or image-based PDF | Can you select the PDF text? |
What causes Mercury xRM parsing errors most often
Tables in the header The name and contact block inside a table is the most common failure. The parser reads table content unpredictably, and the fields Dynamics needs most come through empty.
Graphics and photos Logos, headshots, and skill charts aren't parsed and can push surrounding text out of recognisable order.
Merged contact details Phone and email sharing a line — or decorated with symbols — won't split into separate Dynamics fields.
Inconsistent date formats Mixed date styles across roles cause skipped positions or wrong durations in the record timeline.
Scanned or image-based PDFs No selectable text, nothing to parse. The record saves with empty fields.
Step-by-step fix for Mercury xRM parsing errors
- Remove the header table. Name and contact block in plain text at the top of the body.
- Delete graphics. Photos, logos, and charts go; client branding can be re-applied on output.
- Stack contact details. Phone and email on separate lines, no symbols.
- Standardise every date to one format across all roles.
- Confirm the file is text-based — convert scanned PDFs to .docx.
- Re-upload to a test record and check the mapped fields in Dynamics before processing the batch.
How to prevent Mercury xRM parsing errors
- Standardise on a single-column, table-free CV template across the team.
- Check the name and contact fields on every new record — they fail first.
- Batch-clean at volume with Distill rather than correcting Dynamics records by hand.
- Keep a 30-second pre-upload check: tables, graphics, contact lines, dates, file type.
When to automate this
- You process 20+ CVs weekly through Mercury xRM.
- Bad parses are creating cleanup work inside Dynamics.
- You also need candidate data anonymised before client submission.
Distill strips tables and graphics, splits contact details, normalises dates, and outputs a clean .docx tuned for Mercury xRM — before you import.
FAQ
Q: Why is Mercury xRM missing the candidate's name? A: It's in a header table or graphic. Move it to plain body text.
Q: Contact details merged into one field. Why? A: They shared a line or used symbols. Put each on its own line.
Q: A whole role disappeared from the record. What happened? A: Inconsistent dates or a table in the experience block. Standardise and flatten, then re-upload.
Q: Can Mercury xRM parse scanned CVs? A: No — there's no selectable text. Convert to a text-based file first.
Q: Does Distill integrate with Mercury xRM or Dynamics? A: No direct integration. It cleans CVs before you import them.
If parsing errors keep polluting your Dynamics records, Distill cleans every CV to spec automatically. Try Distill free.