You open a SolidWorks drawing, insert a BOM table, and two extra columns appear with headers “hide1” and “hide2”. They contain no data, they don’t correspond to any custom property you’ve defined, and deleting them fixes the problem — until someone inserts a new BOM from the same template and they’re back.

This is a BOM template corruption issue, and it’s specific enough that most Google searches for it return outdated forum threads pointing at deleted Dassault knowledge base articles. Here’s what’s actually happening and how to fix it permanently.

What a SolidWorks BOM Template File Actually Is

BOM templates are stored as .sldbomtbt files, typically in:

C:\ProgramData\SOLIDWORKS\SOLIDWORKS <version>\lang\english\bom-template\

You can also store them in a shared network location and point all workstations at it via Tools → Options → System Options → File Locations → BOM Templates.

The file format is a ZIP archive containing XML. You can open it with any archive tool:

template.sldbomtbt
├── BOM.xml          ← column definitions and layout
└── meta.xml         ← version and metadata

BOM.xml defines every column in the table: property name, header text, width, visibility, column type. When a column is hidden in the BOM (right-click a column header → Hide), SolidWorks marks it hidden in the XML but keeps the column definition. When that state is saved as a template, the hidden column definition persists.

Why “hide1” and “hide2” Appear

The column definitions in BOM.xml use a <PropertyName> element to bind the column to a SolidWorks property (like Description, Material, or a custom property from the file). When a column is hidden, SolidWorks writes:

<Column>
  <PropertyName></PropertyName>
  <Header>hide1</Header>
  <Visible>false</Visible>
  <Width>15</Width>
</Column>

The <PropertyName> is empty because the column’s binding was lost during the hide operation. SolidWorks auto-generates the header as hide1, hide2, and so on based on position.

This happens most often through one of two paths:

Path 1 — Template saved while BOM has hidden columns. Someone hides a column they don’t want to see (e.g., a SUPPLIER column that isn’t filled in yet), then uses File → Save Table Template. The hidden column definition, with its empty property binding, goes into the template. Every new BOM from that template inherits the ghost columns.

Path 2 — Multi-configuration BOM with mismatched column sets. When a BOM displays data across multiple configurations, and different configurations have different custom properties defined, SolidWorks can generate “placeholder” columns for properties that exist in some configurations but not others. If the template is saved mid-workflow during a multi-config BOM, those placeholder columns end up with no name.

Fix 1: Clean the Template Directly (Permanent Fix)

This works for all cases. You’re editing the XML in the template file.

  1. Copy the template file to a safe location before editing.

  2. Open the .sldbomtbt file in 7-Zip or Windows’ built-in ZIP handler. Navigate to BOM.xml and extract it.

  3. Open BOM.xml in any text editor. Search for hide1, hide2, etc. You’ll find <Column> entries with empty <PropertyName> tags.

  4. Delete those <Column> entries entirely. Each is a self-contained block; remove the full element from opening <Column> to closing </Column>.

  5. Verify the remaining column order makes sense. Column numbering isn’t stored explicitly — order in the XML is order in the table.

  6. Save the modified BOM.xml and drag it back into the .sldbomtbt archive, replacing the original.

  7. Test: close SolidWorks, reopen a drawing, and insert a BOM using the cleaned template. The ghost columns should be gone.

Fix 2: Rebuild the Template from a Clean BOM (Safer for Non-XML Users)

If editing XML manually isn’t comfortable:

  1. Open a drawing that has a BOM with the ghost columns visible.
  2. Show all hidden columns: right-click the BOM table → Hide/Show Columns. Enable everything. The actual “hide1” columns will appear in this dialog — these are the ones with empty or garbled names.
  3. Delete the hide1/hide2 columns using right-click → Delete Column. Do not use Hide.
  4. Verify the remaining columns look correct.
  5. Right-click the BOM → Save Table Template. Save with a new name to avoid overwriting your working template until you’ve confirmed the new one is correct.
  6. Insert a new BOM table from this clean template in a test drawing to confirm no ghost columns appear.

The Multi-Configuration Case

If your assemblies use multi-configuration BOMs (the BOM shows one row per configuration), the fix is the same but diagnosing it requires one extra check.

Multi-config BOM tables in SolidWorks read properties from the @<configuration-name> property scope. If PART_NUMBER@Config-A is defined but PART_NUMBER@Config-B is not, SolidWorks may insert a placeholder column for the missing config. These also appear as hide1-style columns.

To prevent recurrence:

  • Ensure all configurations in a multi-config assembly define the same set of custom properties. Empty value is fine; undefined property is not.
  • Before saving a template from a multi-config BOM, switch to the single configuration view first, confirm column cleanup, then save.

Preventing Corruption on Shared Templates

If multiple workstations share a BOM template from a network path, template corruption tends to propagate the moment one engineer saves a dirty template over the shared copy. Two practices that prevent this:

Write-protect the shared template directory and require engineers to save templates locally first, then submit to a designated person for review before the shared copy is updated. This is the same discipline as write-protecting your /released/ CAD folder.

Version the template file. Treat .sldbomtbt files like any other engineering asset — keep copies with version suffixes (bom-standard-v03.sldbomtbt) and don’t overwrite old versions. CAD file management best practices applies to templates too.

Downstream Impact on BOM Exports

Ghost columns don’t just look wrong — they create noise in any downstream export. If you’re using SolidWorks BOM to Excel export via macro or the native Save As table, the hide1/hide2 columns will appear in the spreadsheet with empty data, requiring post-processing to clean up. If your ERP import depends on a fixed column layout, the presence of unexpected columns will often cause the import to fail silently.

Fix the template before establishing any downstream automation that depends on column position or count.

API Approach for Bulk Template Repair

If you have a collection of templates to clean and want to automate it, the .sldbomtbt XML structure is stable enough to write a script against:

import zipfile
import shutil
import xml.etree.ElementTree as ET

def clean_bom_template(src_path, dst_path):
    """Remove hide1/hide2 ghost columns from a SolidWorks BOM template."""
    shutil.copy2(src_path, dst_path)

    with zipfile.ZipFile(dst_path, 'r') as z:
        bom_xml = z.read('BOM.xml')

    tree = ET.fromstring(bom_xml)
    columns_parent = tree.find('.//Columns')

    if columns_parent is None:
        return  # unexpected structure

    ghost_columns = [
        col for col in columns_parent.findall('Column')
        if (col.findtext('PropertyName') or '').strip() == ''
    ]

    for ghost in ghost_columns:
        columns_parent.remove(ghost)

    cleaned_xml = ET.tostring(tree, encoding='unicode')

    with zipfile.ZipFile(src_path, 'r') as zin:
        names = zin.namelist()
        with zipfile.ZipFile(dst_path, 'w', zipfile.ZIP_DEFLATED) as zout:
            for name in names:
                if name == 'BOM.xml':
                    zout.writestr(name, cleaned_xml)
                else:
                    zout.writestr(name, zin.read(name))

    print(f"Removed {len(ghost_columns)} ghost column(s) from {src_path}")

Run this against your template directory to batch-clean all templates before distributing to the team. The script reads the <PropertyName> element and removes any column whose property name is empty — which is the only condition under which hide1/hide2 headers appear.

Why This Doesn’t Happen With Table-Driven BOMs

If your team uses SolidWorks BOM with CadShift, or any API-driven export that bypasses the table template system entirely, ghost column pollution doesn’t enter the export pipeline — the API reads property values directly from the model, not from column definitions in a template file. Template corruption is a problem of the drawing table layer specifically.

For teams doing high-volume DXF + BOM exports, batch DXF export from SolidWorks handles the geometry side; making sure your BOM template is clean before exporting is the drawing side of the same quality gate.