The XER format is a tab-delimited text export structured into tables (PROJECT, PROJWBS, TASK, TASKPRED, CALENDAR, RSRC, ACTVCODE, TASKACTV, among others), each prefixed with %T and its columns with %F. Its apparent simplicity hides a strict constraint: every row references internal identifiers (task_id, wbs_id, clndr_id) that must exist elsewhere in the same file. A single orphaned reference is enough to break the import, sometimes with an unhelpful error message.

Diagnose before you fix

Before making any correction, open the XER in a text editor capable of handling large tab-delimited files (never Excel on the first pass — it reformats quotes and delimiters, which makes the corruption worse). Identify the table at fault from the P6 error message, then isolate the affected rows using their unique identifier.

The three most common causes, in order of likelihood:

  • Orphaned WBS — a TASK row references a wbs_id missing from the PROJWBS table, typically after a manual WBS node deletion in a partial export.
  • Missing calendar — a clndr_id referenced by an activity doesn't exist in the file's CALENDAR table, common when merging schedules from different P6 environments where calendar IDs don't line up.
  • Unmapped activity codes — the ACTVCODE table defines values that don't exist in the target environment, or whose actv_code_type_id means something different from one project to another.

Restructuring a WBS without breaking relationships

Faced with a disorganised WBS, the temptation is to rebuild it directly in P6 by drag-and-drop. On a schedule of several hundred activities, this is risky: P6 recalculates hierarchy identifiers on the fly and can silently break cross-package predecessor/successor links.

The safer method is to rework the hierarchy directly in the XER's PROJWBS table — reassigning parent_wbs_id values consistently — then re-importing, rather than manipulating the tree in the graphical interface on an already fragile file.

Calendars: the silent source of wrong dates

A misassigned calendar doesn't always trigger an import error — which is the worst-case scenario, because the schedule opens normally but the calculated dates are wrong. A missing public holiday, a 5-day calendar applied to an activity that should follow a 7-day one (continuous equipment erection, for instance), and the entire critical path becomes misleading without any warning being raised.

The systematic check is to compare, activity by activity on critical work packages, the assigned clndr_id against the calendar actually expected for the nature of the work — a simple control, but one too often skipped during a rushed schedule recovery.

Activity codes: the invisible technical debt

Activity codes are often the first thing sacrificed during a migration or XER merge, because their absence doesn't block the import. The result: a technically functional schedule whose filters, groupings and historical reports no longer work, forcing a manual rebuild of a reporting structure that already existed.

A clean XER file isn't one that imports without an error — it's one whose internal references stay consistent through repeated export/import cycles. That's exactly the level of rigour a Primavera P6 planning consultant brings to a schedule recovery.