How to Read a P6 XER File | Planning Toolkit

An XER file is P6's plain-text export format. Despite the intimidating structure, it's tab-delimited text you can open in Notepad — no special tools required. Click any line below to see what it means.

Try it yourself — click a line to explain it

%T TASK %F task_id task_code task_name early_start_date early_end_date clndr_id total_float_hr_cnt %R 5001 A100 Site Establishment 2026-01-05 08:00 2026-01-09 16:00 601 0 %R 5002 A110 Excavation 2026-01-12 08:00 2026-01-20 16:00 601 400 %T TASKPRED %F task_pred_id task_id pred_task_id pred_type lag_hr_cnt %R 10001 5002 5001 PR_FS 0

Click any highlighted line above to see what it declares.

The %T / %F / %R structure

Every table in an XER follows the same three-line-type pattern: a %T line names the table, a %F line lists the field names for every row that follows, and each %R line is one record, with values in the same order as the %F line above it. Tab characters separate every field — not spaces, not commas.

Character encoding

Don't assume an XER is UTF-8. Exports are often written in a legacy Windows code page — commonly Windows-1252 on English-language systems — but this can vary with locale and P6 version. If an activity name contains extended characters (curly quotes, accented letters, the degree symbol) and the file is decoded with the wrong encoding, those characters will be corrupted. A robust parser should detect the encoding or let the user choose it.

Key tables

PROJECT — one row per project in the file, including the data date (last_recalc_date) and scheduling settings like critical_path_type.
TASK — one row per activity: internal key (task_id), Activity ID (task_code), name, dates, calendar assignment, float.
TASKPRED — one row per logic link (relationship) between two activities.
CALENDAR — one row per calendar, with the working/non-working day pattern packed into its own clndr_data field.
TASKRSRC — one row per resource assignment to an activity (units, cost, rates).

How TASKPRED links activities

Each TASKPRED row holds a successor (task_id), a predecessor (pred_task_id), a relationship type (pred_type) and a lag in hours (lag_hr_cnt). Both task references are the numeric internal keys from TASK.task_id, not the Activity IDs you see on screen, so you join back to TASK to read a link as "A100 → A110". The logic network is built from these rows — without them, TASK rows are just an unordered list of activities.

PR_FS

Finish-to-Start: successor starts after predecessor finishes.

PR_SS

Start-to-Start: successor starts once predecessor starts.

PR_FF

Finish-to-Finish: successor finishes once predecessor finishes.

PR_SF

Start-to-Finish: predecessor starts before successor can finish (rare).

Why the stored dates may be stale

A freshly exported XER carries the dates and float from whenever it was last scheduled inside P6 — but nothing forces those numbers to be current. If someone edited logic, durations or calendars after the last F9 (Schedule) run, the stored dates in TASK are stale until it's rescheduled. A tool reading the file directly can trust the stored dates only as much as it trusts that the file was scheduled immediately before export — which is why an independent CPM recompute is a useful cross-check. A recompute also needs calendars, constraints, progress, the data date and the project's scheduling options, and it can still differ from P6 for legitimate reasons, so differences are a prompt to investigate, not proof of an error.

Key takeaway

Reading the raw structure once makes every downstream tool — P6 itself, or an independent recompute — much easier to trust, because you can always go back to the source rows and see exactly what they say.

Open your XER in Plan →