Learning Center

What Is an XER File? Structure and Comparison Pitfalls

Every Primavera P6 schedule export you’ll ever receive as a .xer file is really a stack of separate tables, disguised as one plain-text file. Understanding that structure explains why two exports of “the same” schedule can be harder to compare than they look.

A Plain-Text File, Not a Database -- But Shaped Like One

Open a .xer file in any text editor and it reads as a series of tab-separated rows. Three prefixes carry all the structure:

%T marks the start of a new table, followed by its name (e.g. %T TASK).
%F lists that table’s column names, in order.
%R is one data row, with values in the same order as the%F line above it.

A single export can contain a few dozen of these tables back to back -- most of them administrative (currency types, non-work days, activity-code definitions) and a handful that carry the actual schedule.

Three tables from one real export, simplified. Every relationship in TASKPRED references activities by their internal task_id, not by the human-readable task_code shown in P6’s own interface.

The Tables That Actually Matter for Delay Analysis

Of the dozens of tables a real export contains, a small handful carry the information a schedule comparison or delay analysis actually needs:

Table	What it holds
PROJECT	One row per project in the file -- project ID, name, data date.
PROJWBS	The Work Breakdown Structure: every WBS node, its parent, and which project it belongs to.
TASK	One row per activity -- ID, name, dates, durations, float, status, and which WBS node it sits under.
TASKPRED	Every relationship (predecessor/successor pair): which two activities, what type (FS/SS/FF/SF), and any lag.
CALENDAR	Work calendars -- which days and hours each activity's dates are calculated against.
TASKRSRC	Resource and cost assignments, linked back to TASK by activity ID.
ACTVCODE / TASKACTV	Activity codes (custom classification values) and which activities carry which code.

Why Activity ID Reuse Breaks Naive Comparisons

Every table above identifies an activity by its internal task_id -- a database row number P6 assigns, not the human-readable Activity ID (task_code, e.g. “A1010”) that appears on screen. That distinction matters enormously for comparison: a naive tool that matches activities across two exports by task_id alone will silently treat “A1010” in export 1 and “A1010” in export 2 as two completely unrelated activities the moment task_id happens to differ between them -- which can genuinely happen across a re-import, a copy between projects, or certain administrative operations, even though nothing about the activity itself actually changed.

The same problem runs in the opposite direction too: matching purely by task_code can also mislead if a scheduler renumbers or renames an activity between updates -- what looks like “this activity vanished and a new one appeared” may really be the same work under a new code, and vice versa: an unrelated new activity happening to reuse an old code reads as “nothing changed” if the comparison trusts the code alone.

Claims Digger’s comparison engine is built around exactly this problem. It matches activities across two uploaded snapshots the way a human reviewer actually would -- by their real-world identity, not a database row number that can shift for reasons having nothing to do with the schedule itself -- and surfaces duplicate-code and reuse cases as their own explicit finding rather than silently guessing. See how it works.

Frequently Asked Questions

Is XER the same as XML?: No. Despite the similar-looking three-letter extension, .xer is Oracle Primavera P6's own plain-text, tab-delimited export format -- not XML. Opening one in a text editor shows readable rows starting with %T (table name), %F (field names), and %R (a data row), not angle-bracket tags.
Why do two exports of the 'same' schedule sometimes have different activity IDs?: task_id is an internal database row identifier, not the human-readable Activity ID (task_code) shown on screen in P6. Re-importing, copying between projects, or certain administrative operations can regenerate task_id values even when task_code and everything else about the activity look identical.
Can an .xer file be opened in Excel directly?: Not usefully -- Excel will try to parse the whole file as one flat table, which doesn't work because it actually contains many different tables (TASK, TASKPRED, PROJWBS, etc.) stacked one after another, each with its own column layout. It needs a parser that understands the %T/%F/%R structure to split it apart correctly.

Part of the Claims Digger Learning Center. Related reading: XER File (glossary) · Activity ID Reuse (glossary) · Full glossary