KiCad schematic parity: keeping schematic and PCB in sync

Parity means both editors describe one design

KiCad stores the logical circuit in .kicad_sch files and the physical layout in a .kicad_pcb file. They are separate documents. Saving a changed schematic does not silently add a footprint or rename a net on the board; you must forward-annotate those changes with Tools → Update PCB from Schematic.

A board has schematic parity when every expected symbol has the correct linked footprint, pad-to-net assignments agree, references and values are current, and unexplained board-only parts are absent. DRC can be electrically and geometrically clean while parity is broken. For example, deleting an LED from the schematic does not guarantee its old footprint disappears from an already routed board.

Treat the schematic as the normal source of truth for components and connectivity. Layout-specific information—placement, routing, zones, stackup, and mechanical geometry—belongs on the board.

Understand how symbols and footprints stay linked

Modern KiCad links a symbol instance to its footprint with a unique identifier (UUID), not merely the visible reference U3 or R17. That allows annotation to rename a reference without discarding the placed and routed footprint. When you run Update PCB from Schematic, KiCad finds the existing footprint by that identifier and updates its reference, value, fields, footprint assignment, and nets as required.

Deleting a symbol and placing a visually identical replacement creates a new UUID. From KiCad’s perspective, the original footprint belongs to a deleted symbol and the replacement needs a new footprint. The proposed update may therefore remove a carefully placed part and add another to the unrouted group.

The update dialog offers Re-link footprints to schematic symbols based on their reference designators for recovery from that situation. Use it only when you have deliberately reconstructed symbols and have verified that reference designators identify the correct pairs. After the one-time repair, return to normal UUID linking. Leaving reference-based relinking enabled as a habit can connect the wrong objects after annotation changes.

Use a schematic-first change sequence

For a normal electrical change:

1. Edit the schematic.
2. Annotate any new symbols and assign their footprints.
3. Run ERC and save the schematic.
4. Open Tools → Update PCB from Schematic or press F8.
5. Read the Changes To Be Applied list before clicking Update PCB.
6. Place new footprints, repair routing, refill zones with B, and run DRC.

The preview is a change review, not a dialog to click through reflexively. An unexpected removal, a long list of re-linked parts, or many changed nets usually signals a source edit worth understanding before board geometry is touched. Save the update report when a release process needs an audit trail.

Footprint assignments should also originate in the schematic. If you change a package only in PCB Editor, the next forward annotation can put the old assignment back. Either make the assignment in the schematic first or use controlled back annotation.

Back-annotate only intentional board-side changes

KiCad provides Tools → Update Schematic from PCB for changes made on the physical side. It can transfer reference designators, values, attributes, footprint assignments, other fields, and net names. Each class of change can be enabled independently.

This is useful after geographical reannotation or when a reviewed footprint substitution was made during layout. It is not a general “make everything match” button. Before applying it:

• save or commit both source files;
• select only the property types you intend to transfer;
• inspect every proposed change;
• rerun ERC and then forward annotation to prove the project is stable.

Changing connectivity from PCB Editor is especially easy to misread. A net rename that looks harmless on copper may alter labels across a hierarchical schematic. Make electrical intent clear in the schematic whenever possible.

Run schematic parity as part of DRC

In the PCB Editor’s Design Rules Checker, enable schematic parity checks and review their section alongside geometry findings. Typical parity violations include:

• Missing footprint: a schematic symbol expected on the board has no linked footprint.
• Extra footprint: a board footprint has no corresponding schematic symbol.
• Duplicate footprints: more than one schematic-linked footprint uses the same reference.
• Footprint or net mismatch: properties or pad connectivity disagree with the linked symbol.

For an extra footprint, decide whether it is accidental or deliberately board-only. Logos, fiducials, and purely mechanical features can be marked with the appropriate board-only property. Electrical parts are easier to maintain when represented in the schematic, even if they are mounting hardware or test points.

KiCad 9 can run the same check headlessly:

mkdir -p build/reports

kicad-cli pcb drc \
  --output build/reports/drc.json \
  --format json \
  --severity-all \
  --schematic-parity \
  --exit-code-violations \
  hardware/controller.kicad_pcb

Run it from the project directory so KiCad can find the matching project and schematic. The --schematic-parity flag makes the relationship part of the command-line gate rather than relying on a developer’s remembered GUI checkbox. See the full headless KiCad automation sequence for pairing this with ERC and fabrication exports.

Diagnose parity failures at the source

If a footprint is missing, first check whether the symbol is excluded from the board or lacks a footprint assignment. Then run Update PCB from Schematic and inspect the preview. Manually copying a similar footprint onto the board does not establish the correct link.

If nets differ, compare pad numbers. Symbols and footprints connect through matching pin and pad identifiers: symbol pin 3 maps to footprint pad 3. A visually plausible footprint with reversed or differently named pads can create broad net changes. The unconnected-items troubleshooting guide covers the copper symptoms this mismatch often produces.

If fields or values differ, choose which editor contains the reviewed data and update in the correct direction. This matters for purchasing data. A current KiCad BOM with real part numbers should come from the same schematic revision used to update the board.

Make parity part of the release boundary

A reliable release sequence is: clean working tree, ERC, forward annotation review, zone refill, DRC with schematic parity, BOM export, then fabrication export. Record the source commit with the generated package.

Avoid hand-editing references in Gerbers, placement CSVs, or BOM files to make deliverables appear aligned. Those edits create multiple unofficial truths. Fix the KiCad source, regenerate every output, and rerun the checks. Parity is valuable because it proves the manufacturing data is derived from the same circuit the engineer reviewed—not merely from a board that happens to look finished.