ERC vs DRC: What’s the Difference in PCB Design?

ERC checks electrical intent in the schematic

Electrical Rule Check (ERC) reasons about schematic symbols, pins, and nets. A symbol pin has an electrical type—input, output, bidirectional, passive, power input, power output, open collector, and so on. ERC compares the types connected on a net and reports combinations that look impossible or incomplete.

Typical ERC findings include:

• a power-input pin on a net with no declared power source;
• two ordinary outputs connected together;
• an input or power pin left unconnected;
• a no-connect marker attached to a pin that is actually wired;
• inconsistent net labels or hierarchical connections.

ERC does not know whether an I2C pull-up is the right resistance, whether a connector pinout matches its datasheet, or whether 3.3 V is enough current for a radio burst. It checks the intent encoded in symbols. A badly defined custom symbol can therefore make a wrong circuit pass or a correct circuit noisy with false errors.

In KiCad, run Inspect → Electrical Rules Checker in Schematic Editor. Resolve root causes instead of placing No ERC markers until the report is quiet. If a passive power connector legitimately feeds a rail, a PWR_FLAG tells ERC that the net is driven; it does not generate power and should not be used to hide an actually unpowered rail.

DRC checks physical implementation on the PCB

Design Rule Check (DRC) reasons about copper, layers, footprints, holes, board edges, and rules. It evaluates the board’s geometry and connectivity against board setup, net classes, and custom constraints.

Typical DRC findings include:

• copper clearance below the configured minimum;
• a track narrower than its net-class rule;
• an unrouted connection or dangling track;
• annular-ring, via, or drill violations;
• silkscreen over solder-mask openings;
• overlapping courtyards;
• copper too close to the board edge;
• a differential pair violating width, gap, or uncoupled-length rules.

DRC cannot tell that a USB-C footprint is mirrored if its pads follow the schematic netlist consistently. It cannot determine a trace’s true current capacity without accurate stackup, copper, temperature, and rule inputs. A green report means “the board satisfies the encoded rules,” not “the board is fit for manufacture.” The KiCad DRC violation guide explains how to interpret individual report types.

Schematic-to-PCB parity joins the two views

ERC can pass on an updated schematic while DRC passes on an old PCB. The missing step is parity: are the symbols, footprints, pin mappings, and nets used by the board consistent with the schematic?

In KiCad, use Tools → Update PCB from Schematic after accepted schematic changes. Then run DRC with schematic parity enabled. This catches classes of stale-design problems such as a net renamed only in the schematic or a footprint association changed after placement. Read keeping schematic and PCB in sync for a repeatable workflow.

Parity still cannot prove a custom symbol’s pin 4 represents the same physical function as footprint pad 4. That is a datasheet audit.

Run both from the command line

KiCad 9 can produce reports and fail a CI job when violations exist:

mkdir -p build/reports

kicad-cli sch erc \
  --exit-code-violations \
  --output build/reports/erc.rpt \
  hardware/controller.kicad_sch

kicad-cli pcb drc \
  --exit-code-violations \
  --schematic-parity \
  --output build/reports/drc.rpt \
  hardware/controller.kicad_pcb

Run kicad-cli sch erc --help and kicad-cli pcb drc --help on the installed version before copying flags into CI. Pin that KiCad version so the rules engine and report format do not change silently. The command-line ERC guide covers exit codes and automation in more detail.

Keep the generated reports as build artifacts with the design commit. A report without its exact schematic/PCB revision is weak evidence because the files may have changed immediately afterward.

Triage violations without training yourself to ignore them

Use the same sequence for every finding:

1. Locate it and inspect the connected circuit or geometry.
2. Decide whether the design, library data, or rule is wrong.
3. Fix the root cause.
4. If it is an intentional exception, add the narrowest exclusion with a written reason.
5. Rerun the full check.

Do not globally relax a clearance because one connector has fine-pitch pads. Use a footprint- or area-specific rule justified by the fabricator’s capability. Do not mark unused pins with No ERC merely to reduce the count; use explicit no-connect markers when the pin is intentionally unused.

Review exclusions as part of every release. An old exclusion can suppress a new error after a footprint moves or a net changes. Error, warning, and exclusion counts should be visible in the release manifest.

Know what neither check catches

ERC and DRC cannot fully verify:

• manufacturer part number, package variant, or lifecycle;
• connector mating orientation and cable pinout;
• analog stability, RF matching, or antenna performance;
• regulator transients and thermal limits;
• enclosure collisions when models are absent or inaccurate;
• assembly-house process limits not encoded as rules;
• whether the product meets its functional requirements.

Add schematic review, datasheet pin audit, BOM validation, 3D/mechanical review, fabrication-output inspection, and a bring-up test plan. The pre-order DFM checklist picks up where automated design rules stop.

The distinction is simple: ERC checks the logical electrical model; DRC checks the physical board model. A releasable PCB needs both models, parity between them, accurate rules, and human evidence for the properties those models do not represent.