What Is Schematic Capture, and How Does It Actually Work?

Detailed Explanation

Schematic capture is the first formal step of PCB design: representing a circuit's components and their electrical connections using standardised symbols in an EDA (electronic design automation) tool, rather than as a hand-drawn or conceptual diagram. Each component is placed as a symbol with labelled pins; wires drawn between pins define electrical nets. Once the schematic is complete, the EDA tool generates a netlist, the definitive record of which pins are electrically connected, which the layout stage uses to know what needs to connect to what, regardless of where components are physically positioned on the board.

For a step-by-step walkthrough of schematic entry in KiCad specifically, see How to Use KiCad: Schematic Entry and PCB Layout Workflow; for the equivalent Altium Designer workflow, see How to Use Altium Designer: Schematic Entry and PCB Layout Workflow.

Net Labels, Hierarchical Labels, and Global Labels

Not every electrical connection in a schematic needs a drawn wire. Every EDA tool provides label types that connect pins by matching name rather than by a physical line on the page, and the scope each label type connects across is what makes them different tools for different jobs, not interchangeable ways of writing the same thing:

A net label is the simplest case and the one every schematic uses even on a single flat sheet: two pins with a matching net label connect exactly as if a wire had been drawn between them, but on a multi-sheet design that same net label does not reach beyond the sheet it's placed on. Reaching across sheets requires either a hierarchical label (scoped to the sheet hierarchy the signal belongs to, and verifiable by ERC) or a global label (reaching anywhere in the project by name match alone, with no hierarchy check). Exact terminology varies by tool: Altium Designer builds the same hierarchical connection from a sheet symbol's Sheet Entry ports matched to a Port object inside the sub-sheet, functionally equivalent to KiCad's hierarchical labels and sheet pins, but the underlying scoping concept is consistent across EDA tools.

The practical risk sits with global labels: because they connect anywhere in the project purely by matching text, an accidental duplicate global label name on two unrelated sheets creates a real, silent short that no Electrical Rule Check will catch, since as far as ERC is concerned that connection was intentional. The safer default on any multi-sheet design is to reach for hierarchical labels first and reserve global labels for signals that genuinely need project-wide reach. For KiCad's full sheet-symbol and hierarchical-label workflow, including reused sub-sheets and multi-level hierarchies, see How Do You Design a Hierarchical Schematic in KiCad?

Annotation and the Electrical Rule Check (ERC) Workflow

Annotation is the process of assigning each schematic symbol a unique reference designator (U1, R1, C1, and so on), and it happens before a netlist can be generated: an unannotated or duplicate reference designator makes it impossible for the netlist to unambiguously identify which physical component a given set of pins belongs to. Most EDA tools annotate automatically (sequentially, or grouped by sheet or by functional block), and most also support re-annotation, renumbering references after schematic edits without disturbing existing wiring. Some tools additionally support back-annotation: if a layout tool swaps equivalent gates within a multi-unit symbol (for example, choosing which of a quad NAND gate's four identical units routes most cleanly) or repositions pins for a package with swappable pin functions, back-annotation writes that choice back into the schematic so the two stay in sync rather than silently diverging.

With the schematic annotated and wired, the standard sequence into layout is:

1. Annotate every symbol with a unique reference designator.
2. Run ERC and resolve every reported error before proceeding; treat warnings on a case-by-case basis rather than dismissing them by default.
3. Assign footprints to any symbol that doesn't already have one linked.
4. Generate the netlist (or, in tools like KiCad and Altium, transfer directly to the PCB editor, which performs this step internally).
5. Re-run ERC after any later schematic change, since a change that looks minor, adding one net or renaming one label, can introduce a new conflict that a one-time ERC pass at the start of the project would never catch.

ERC itself is a logical check distinct from the PCB layout's Design Rule Check (DRC): it operates purely on the schematic's symbols and connections, with no knowledge of physical geometry. A typical ERC pass flags:

• Unconnected pins that aren't explicitly marked as a deliberate no-connect.
• Conflicting drivers, such as two output pins wired directly to the same net.
• Undriven power pins, a power input pin with no power source connected to its net.
• Duplicate reference designators, usually a sign that annotation hasn't been run or completed since the last edit.

ERC is a structural and logical check, not a functional one: it cannot tell you whether the circuit does what you intend, only whether the connections as drawn are internally consistent. A schematic can pass ERC cleanly and still be functionally wrong, so ERC belongs alongside a manual design review, not in place of one.

Practical Examples

A microcontroller-based sensor board's schematic capture stage involves placing the MCU symbol, its decoupling capacitors, the sensor's symbol, any pull-up resistors its bus requires, and a power regulation block, then wiring each net: power rails, ground, and signal connections like the I2C bus between MCU and sensor. The resulting netlist tells the layout tool that the MCU's SDA pin and the sensor's SDA pin belong to the same net, without yet saying anything about where either component sits on the board.

Reusing a schematic block, a regulator circuit or a connector's protection network, across multiple projects is common practice precisely because schematic capture separates "what connects to what" from "where it physically goes," letting a proven circuit block be dropped into a new design and re-wired to new nets with confidence that its internal connections are unchanged.

On a design split across sheets, for example a power-supply sheet, an MCU/peripheral sheet, and an analog front-end sheet, the +3V3 rail is a typical candidate for a global label (it needs to reach every sheet), while a sensor's internal feedback signal that only matters within its own sub-circuit is a typical candidate for a hierarchical label, scoped to stay local to that sheet's hierarchy rather than reachable from anywhere else in the project.

Schematic Symbol Reuse and Library Management

Schematic symbols live in libraries, and how those libraries are organised has a direct effect on how safely symbols can be reused across a design and across projects. Most EDA tools distinguish between a project-scoped library (symbols specific to one design, kept alongside it and handed over intact to a colleague or fabricator) and a shared or global library (symbols reused across many projects, such as a company's standard parts). Altium extends this further with database and cloud-vault libraries that bundle a symbol, its footprint, and supplier data as a single managed unit with lifecycle states like draft, released, and obsolete; KiCad keeps symbol and footprint libraries as separate plain-text files referenced from project- or user-level library tables. See How Do You Create and Manage KiCad Footprint and Symbol Libraries? for the KiCad-specific mechanics.

The reason library discipline matters for schematic capture specifically: a symbol's pin numbering is what the netlist relies on to map each schematic pin to the correct physical footprint pad. A reused symbol copied from an older project, or a shared library that drifts out of sync with the footprint it's linked to, can carry an outdated or simply wrong pin mapping into a brand-new design without any visible sign of a problem until the board is assembled. See PCB Footprint vs Schematic Symbol: What Is the Difference? for how that symbol-to-footprint link works and why neither ERC nor DRC catches a mismatch that exists only in the mapping between the two.

Design Considerations

• Run ERC before moving to layout, not after. An unconnected power pin or conflicting net is far cheaper to fix in the schematic than after parts have already been placed around it.
• Use consistent, descriptive net names for important signals (clocks, resets, specific bus lines) rather than relying on auto-generated net numbers. It makes the netlist, and later the routed board, much easier to debug.
• Default to hierarchical (or scoped) labels over global labels on any multi-sheet design. The scoping hierarchical labels provide is a real safeguard against an accidental duplicate label name silently connecting two unrelated sub-circuits.
• Keep symbol libraries consistent with footprint libraries. A schematic symbol with the wrong pin-to-pad mapping silently produces a board that doesn't match the intended circuit, and ERC won't catch a mismatch that exists only in the footprint link.
• Annotate reference designators logically (grouping by function or board section) so the schematic and the eventual placed board read in a similar order. It materially speeds up debugging a populated board against its schematic.
• Schematic-to-layout continuity: working with the same team for both schematic capture and PCB layout, as Zeus Design's PCB service provides, eliminates the translation errors that arise when capture and layout are handled by separate people unfamiliar with each other's conventions.

Common Mistakes

• Skipping the Electrical Rule Check and discovering an unconnected pin or shorted output only after the board is fabricated and populated.
• Relying on a component's default or auto-generated symbol without confirming pin numbering matches the actual part. A transposed pin pair is invisible in the schematic but fatal on a populated board.
• Reaching for a global label as a default instead of a hierarchical label on a multi-sheet design, losing the scoping protection hierarchical labels are meant to provide.
• Treating schematic capture as a formality to rush through, when in practice the net naming and structure decided here directly shapes how readable the eventual layout and any future revision will be.
• Letting the schematic and footprint library drift out of sync across projects, so a symbol reused from an older design silently links to an outdated or incorrect footprint.