You export the schedule to SDEF for the Corps of Engineers, the converter runs for a few seconds, and it stops. The log names an activity ID you did not know was a problem. Nothing is wrong with your logic, your durations or your cost loading. The file failed on a column width.
This article explains the one condition that makes the SDEF conversion stop outright, why it is usually invisible inside P6, and how to clear it before the schedule goes anywhere.
What the converter does to an activity ID
SDEF, the Standard Data Exchange Format defined in ER 1-1-11 Appendix A, is a fixed-column text file. Every field has a fixed width, and the activity ID field holds 10 characters.
P6 allows much longer IDs. Oracle's own guide to the conversion, Considerations When Converting a Project to SDEF, describes what happens to a longer one: the ID is cut to its first 10 characters. Most of the time that is harmless. It stops being harmless when two IDs share their first 10 characters.
Take two activities a scheduler might reasonably create:
MECH-AHU-1010— Set AHU-1MECH-AHU-1020— Pipe AHU-1
Cut to 10 characters, both become MECH-AHU-1. Two activities now carry the same ID, and the conversion is aborted. In a real schedule this rarely happens to one pair. A family of IDs built on one prefix collides as a group, and a dozen activities can fail together.
Why you do not see it in P6
Inside P6 the IDs are different, so nothing warns you. Sorting by ID does not help either, because the collision only exists after the cut. The first time anyone sees it is the converter's log, which is usually the afternoon the update is due.
The specification already forbids the long ID
UFGS 01 32 01.00 10, the Corps of Engineers' Project Schedule section, settles this independently of SDEF. Paragraph 3.12.i reads:
i. Activity ID's must not exceed 10 characters.
So an ID longer than 10 characters is a finding in any schedule submitted under that section, whatever file format carries it to the Government. The SDEF collision is the most visible consequence of breaking that rule, not a separate rule.
How to fix it
- List every activity ID longer than 10 characters. In P6, add a column showing the ID and filter or sort by its length, or export the activity table and count the characters.
- Renumber them to 10 characters or fewer, with unique first 10 characters. P6's renumbering command can do this in bulk for a selection of activities. Keep the numbering readable, for example
MAHU1010andMAHU1020. - On a schedule that is already approved, agree the renumbering with your Resident Office first. A changed ID can read in the next comparison as one activity deleted and another added, and unexplained deletions draw questions of their own.
- Convert again and read the log. The conversion can also shorten descriptions to 30 characters and cut other fields without stopping. Those changes do not abort the file, but what reaches the Government is then not exactly your schedule.
Two more limits worth knowing
Oracle's conversion guide also lists limits that rarely bite but cost a day when they do. An SDEF file is limited to 10,000 activities, and the format does not support durations over 999 days. A long level-of-effort activity spanning a multi-year project is the usual candidate for the second one.
Is SDEF still the only way in?
No. RMS, the Corps of Engineers' construction management system, has accepted P6 XML schedule imports since 2023 and lists XER in the same import screen since January 2026. A file uploaded that way is not cut to SDEF's columns. The 10-character rule in 3.12.i still applies to the schedule itself, though. Ask your Resident Office which file your contract expects, and fix the IDs either way.
This article describes published specification text and vendor documentation. It is not an engineering opinion. Your contract's own specification governs your schedule.