You build a steel frame as a weldment in one part file. Twelve identical 1500 mm long pieces of 50x50x3 square tube, plus eight 800 mm cross braces of the same profile. The cut list folder shows the right rollups: the long pieces grouped under one folder, the short pieces under another. The properties match. Then you drop the part into a parent assembly with a few other weldments, drop a BOM on the drawing, and the cut list items from the second weldment refuse to combine with the matching items from the first. Same profile. Same length. Same description. Different rows.

This is a very specific, very repeatable failure. The cause is almost never inside the cut list properties — it is in the parent file name SolidWorks is using as the unspoken merge key. Once you know that, the fix is small and the consequences for downstream DXF naming and BOM exports are large.

What SolidWorks Actually Compares

When SolidWorks builds a top-level BOM that includes weldment cut list items, it does not just look at the cut list folder properties. It builds a composite identity for each row from three things, in this order:

  1. The parent part file the cut list item lives inside (its filename, minus the extension)
  2. The cut list folder name SolidWorks generated for that body
  3. The cut list folder properties (LENGTH, MATERIAL, DESCRIPTION, and any custom properties)

For two cut list items in the same parent part to merge, properties 2 and 3 are sufficient — the consolidation logic inside a single weldment is well-documented. For two cut list items across different parent parts to merge in an assembly BOM, the BOM also needs the parent file name to match, because the BOM column “Part Number” defaults to filename for component-level entries. For cut list items the cell falls back to the cut list folder name, but the row identity still uses the parent file as a discriminator.

In other words: two physically identical pieces of tube in two different weldment files are, from the BOM’s point of view, two different rows because they came from two different parents. No amount of cleaning up cut list properties will collapse them.

The PARTNUMBER Property Override

The override exists. It just isn’t on by default and almost nobody documents it. On any cut list folder you can add a custom property named PARTNUMBER (uppercase). When the BOM evaluates a cut list row, it looks for that property first; if it finds it, that string becomes the row’s part number and the merge key. If two folders in two different parent files both have PARTNUMBER = TUBE-50-50-3-1500, the BOM merges them.

The procedure on a cut list folder is:

  1. Right-click the cut list folder, choose Properties
  2. On the Cut List Summary tab (not the configuration-specific tab), click an empty row
  3. Property Name: type PARTNUMBER
  4. Value / Text Expression: either type a literal value, or build one from existing properties using the $PRP@CutListItem syntax — for example $PRPCUTLIST:"DESCRIPTION"-$PRPCUTLIST:"LENGTH" to use the description and length

Use the Cut List Summary tab rather than the configuration tab unless you specifically need configuration-specific behavior — properties on the summary tab apply across all configurations and survive most insert-part workflows.

There is a related property, SW-Part Number, that you can use as a column source in the BOM if you want filenames in some rows and cut list names in others. They are different mechanisms; PARTNUMBER changes how rows merge, SW-Part Number controls what shows up in the cell. Most teams want PARTNUMBER.

Why Properties Look Identical But Items Still Don’t Combine

Even before the cross-file problem, items inside a single weldment can refuse to combine. The five most common causes, in order of how often we see them in support threads:

1. Trim/extend gaps differ between bodies. Two structural members trimmed against different mating geometry can end up with different end-cut angles even when their nominal lengths are equal. The cut list compares the body geometry, not just the property values. Use Cut List → Properties → Cut List Sorting Options → Faces/Features to Exclude and add the trim feature to the exclusion list. The bodies will then be hashed without the trim contribution and combine.

2. A small extrude cut on one of the bodies. A bolt hole, a notch, a chamfer. The cut creates a different body topology and the cut list treats it as a unique item. If the cut is intentional and the parts genuinely are different, leave it. If the cut is suppressible in the welded state, suppress it in the as-welded configuration only — the flat or simplified configuration can keep the cut for downstream operations without breaking BOM consolidation.

3. The “Make Cut List” feature was inserted in different orders. SolidWorks generates cut list folder names sequentially from the order bodies were created or sorted. If you copy bodies between weldments, the folder name for what looks like the same item can become Cut-List-Item3 in one file and Cut-List-Item7 in another. The folder name is part of the identity. Rename them by hand or set PARTNUMBER to bypass the folder name entirely.

4. The configuration is different between files. Cut list folders are configuration-specific by default. If file A is showing Default and file B is showing Welded, properties on the configuration-specific tab won’t match even when they look identical. Move properties to the Cut List Summary tab whenever you can.

5. A weld gap entered on a structural member feature. Weld gaps are stored on the structural member, not on the cut list folder. Two members with different weld gaps will produce different body lengths even if you typed the same nominal length. Open the structural member feature and check the gap value. This is the most overlooked cause — there’s no visible difference in the cut list properties but the bodies are physically different sizes.

The Detailed Cut List Option

Since SolidWorks 2022, the Detailed Cut List option is available for all BOM types, not just Indented. When enabled, the BOM expands each cut list folder into its constituent rows; when disabled, the folder appears as one row with a quantity. Detailed mode interacts with the merge logic in a way most users don’t expect: even if PARTNUMBER is set, detailed mode shows individual rows rather than the merged group. If your goal is one row per unique cut list type across the whole assembly, leave Detailed Cut List off, set PARTNUMBER on the cut list folders, and use the Indented BOM type.

When you do want a detailed cut list — for example, on a weldment-specific drawing where you want to show a length column per body — enable it on that drawing only. The cut list table feature in a part-level drawing handles this independently of the assembly BOM.

File-Naming Implications for DXF Export

Here is where this becomes more than a BOM display problem. If you are exporting flat patterns or cut lengths as DXF files for the laser, the filename is almost always derived from the cut list item name or a custom property on it. If the cut list folder name is Cut-List-Item7 because that’s what SolidWorks generated, your DXF file is going to be Cut-List-Item7.dxf. The shop floor receives a folder of files named Cut-List-Item7.dxf, Cut-List-Item3.dxf, Cut-List-Item11.dxf and has no way to map them back to the BOM rows.

The correct chain is:

  1. Set PARTNUMBER on every cut list folder (literal or formula-driven)
  2. Build the DXF export filename from PARTNUMBER, not from the folder name
  3. Ensure the DXF metadata embeds the same PARTNUMBER as a layer property or comment

When all three are true, every DXF file matches a BOM row by name, and procurement, shop floor, and engineering speak the same language. Without it, the DXF naming becomes another translation problem on top of the downstream BOM problem PDM doesn’t solve, and the coordination breaks at the engineering-to-procurement handoff.

CadShift uses the cut list PARTNUMBER property as the default filename token when exporting flat patterns and structural member DXFs. Set it once on the cut list folder, and every export — across every parent weldment — gets a consistent, BOM-mergeable name. The bend lines and material thickness still get embedded as DXF layer metadata, which is what fabricators actually want from a DXF beyond the geometry.

A Short Macro to Audit Cut List PARTNUMBER Coverage

If you’ve inherited a few hundred legacy weldments and want to know which ones already have PARTNUMBER set on every cut list folder, this macro logs the gaps. It iterates every cut list folder in the active part and reports any folder without a PARTNUMBER property on the Cut List Summary tab.

Sub Main()
    Dim swApp As SldWorks.SldWorks
    Dim swModel As SldWorks.ModelDoc2
    Dim swPart As SldWorks.PartDoc
    Dim swFeat As SldWorks.Feature
    Dim swSubFeat As SldWorks.Feature
    Dim swCutListFolder As SldWorks.BodyFolder
    Dim swCustomProp As SldWorks.CustomPropertyManager
    Dim partNumber As String
    Dim resolvedValue As String
    Dim wasResolved As Long

    Set swApp = Application.SldWorks
    Set swModel = swApp.ActiveDoc

    If swModel Is Nothing Then Exit Sub
    If swModel.GetType <> swDocPART Then
        MsgBox "Run on a weldment part."
        Exit Sub
    End If

    Set swPart = swModel
    Set swFeat = swModel.FirstFeature

    Do While Not swFeat Is Nothing
        If swFeat.GetTypeName2 = "CutListFolder" Then
            Set swCutListFolder = swFeat.GetSpecificFeature2
            Set swCustomProp = swFeat.CustomPropertyManager
            swCustomProp.Get5 "PARTNUMBER", False, partNumber, resolvedValue, wasResolved
            If Len(Trim(partNumber)) = 0 Then
                Debug.Print "MISSING: " & swFeat.Name
            End If
        End If
        Set swFeat = swFeat.GetNextFeature
    Loop
End Sub

Get5 returns the literal expression in partNumber and the resolved string in resolvedValue. We check the literal because a folder without a PARTNUMBER row at all returns an empty literal; one with an empty value but the row defined will return an empty literal too, which is what we want to flag. Run it across a folder of weldments by replacing swApp.ActiveDoc with an open-and-iterate loop.

What to Standardize at the Template Level

The fix scales when you bake it into the part template. The procedure:

  1. Open weldment.prtdot from the template directory
  2. Insert a placeholder weldment feature so a cut list folder exists
  3. On that folder’s Cut List Summary tab, add a PARTNUMBER property with a default expression — $PRPCUTLIST:"DESCRIPTION"-$PRPCUTLIST:"LENGTH"@@@$PRPCUTLIST:"Bounding Box Length"@CutListItem works for most square and rectangular tube standards
  4. Save the template

Every new weldment built from that template inherits the property. Existing weldments still need a one-time pass with the macro above, but new work stops creating the problem.

The template change pairs well with a shared library approach to design library export settings so that DXF and PDF export options come along with the geometry. When PARTNUMBER, layer mapping, and entity selection are all in the template, the export becomes a one-click operation regardless of who built the file.

The Tradeoff With Configurable Profiles

One case where PARTNUMBER as a hard-coded string causes problems: configurable structural members. If a single profile library file feeds multiple sizes, hard-coding TUBE-50-50-3 on the cut list folder means resizing the profile to 60x60x3 won’t update the part number. The folder still says TUBE-50-50-3. The BOM happily merges parts that aren’t actually the same anymore.

The expression form prevents this. Build PARTNUMBER from the actual structural member properties: $PRPCUTLIST:"DESCRIPTION"-$PRPCUTLIST:"LENGTH". Now the part number reflects the live geometry. If a designer later changes the profile, the part number updates, and the BOM stops over-merging.

For mirrored or handed parts, the same expression-driven approach lets you append -MIR or pull from a custom property only set on the mirrored body. The mechanics are the same as the per-body orientation work covered in multibody DXF export with handed flat patterns.

When the Fix Is Not Worth It

Two cases where PARTNUMBER on cut list folders adds friction without paying back:

  • One-off prototypes. If the assembly will be cut once, hand-edited at the bench, and never reordered, the cost of setting up properties and templates exceeds the value of clean BOM consolidation. A non-merged BOM with twenty rows instead of eight is fine if nobody downstream cares.
  • Detailed shop drawings as the source of truth. Some shops ignore the assembly-level BOM entirely and work from a part-level cut list table on the weldment drawing. In that workflow, cross-file BOM merging is irrelevant because the BOM never crosses files. Set PARTNUMBER only if you need the merged assembly view.

For most shops doing recurring production with assemblies that contain multiple weldments, setting PARTNUMBER once at the template and using an expression-driven value pays for itself in the first reorder. The BOM tells you 24 pieces of TUBE-50-50-3-1500 instead of 12 from one file and 12 from another, and the DXF folder you send the laser has 24 instances of TUBE-50-50-3-1500.dxf ready to nest.