Iso 5807 Flowchart Symbol Standard Explained: Complete Visual Guide and Reference

If you've ever tried to read a flowchart drawn by someone else and couldn't figure out what half the shapes meant, you already understand why the ISO 5807 standard exists. Flowcharts are supposed to make things clearer, not more confusing. ISO 5807 is the international standard that defines what each flowchart symbol means, how to use it, and how to arrange them so anyone trained in the standard can read your diagrams without guessing.

This standard was originally published in 1985 and covers data processing documentation symbols, conventions, and their use in flowcharts. It's not the most exciting document to read cover to cover, but if you work with process diagrams, system documentation, or programming logic, knowing what ISO 5807 puts on the table saves you from miscommunication and redrawn charts.

What exactly is ISO 5807?

ISO 5807 is a standard published by the International Organization for Standardization. Its full title is "Information processing Documentation symbols and conventions for data, program and system flowcharts, program network charts and system resources charts."

It sets out a shared vocabulary of shapes, lines, and annotations used in flowcharts so that diagrams created in one country, company, or team can be understood by another. Think of it like a grammar book for flowcharts. Without it, everyone invents their own shorthand, and diagrams become harder to read the more people are involved.

The standard covers several types of charts:

Data flowcharts showing how data moves through a system
Program flowcharts showing the logic and sequence of operations in a program
System flowcharts showing how hardware, software, and manual processes connect
Program network charts showing relationships between programs
System resources charts showing how system resources are allocated

If you want a broader view of how different flowchart symbol conventions work across business process mapping, the principles overlap with what ISO 5807 defines.

Why does this standard matter for people who draw flowcharts?

Flowcharts are one of the most common ways to document processes. They appear in software engineering, manufacturing, healthcare, business analysis, and education. The problem is that without a standard, two people can draw completely different diagrams for the same process and both think theirs is obvious.

ISO 5807 solves this by defining specific symbols for specific meanings:

Rectangle a process or action step
Diamond a decision point (yes/no, true/false)
Parallelogram input or output of data
Oval or rounded rectangle terminal (start or end of a process)
Arrow or flow line direction of flow
Circle a connector linking parts of the chart on the same page
Off-page connector links to another page or section
Document symbol a step that produces or uses a document

When everyone on a team uses these symbols consistently, a new team member can pick up a flowchart from six months ago and understand it without needing someone to walk them through it.

When would someone actually need to know ISO 5807?

You don't need to memorize the standard cover to cover in most roles. But it becomes relevant in several situations:

Writing technical documentation for software systems where auditors or compliance teams review your process diagrams
Working on international projects where team members from different countries need a shared visual language
Training new staff on business processes standardized flowcharts are easier to teach from
Creating documentation for regulated industries like finance, pharmaceuticals, or aerospace, where referencing standards shows you followed recognized practices
Reviewing or auditing processes if you need to trace how data flows through a system, a standard flowchart is far easier to audit than a freeform diagram

For programmers specifically, understanding what flowchart symbols mean in a programming context ties directly back to how ISO 5807 structured its flowchart symbol definitions for programming logic.

What are the most commonly used ISO 5807 symbols?

Here's a practical breakdown of the symbols you'll run into most often, along with what they represent:

Process (Rectangle) Any operation or action. Example: "Calculate total price" or "Send email notification."
Decision (Diamond) A point where the flow branches based on a condition. Example: "Is the order over $50?" with Yes and No paths leading out.
Input/Output (Parallelogram) Data entering or leaving the process. Example: "Read customer data from database."
Terminal (Oval) The start or end point. Example: "Begin" or "End of process."
Predefined Process (Rectangle with double vertical lines) A process defined elsewhere, often in another flowchart. Example: "Run authentication subroutine."
Manual Operation (Trapezoid) A step performed by a person, not a computer. Example: "Manager approves request."
Document (Rectangle with a wavy bottom line) A step that creates or reads a physical or electronic document. Example: "Print invoice."
Connector (Circle) Used to avoid crossing lines or to link flowchart sections. Often labeled with a letter or number.
Flow Lines (Arrows) Show the direction the process follows.

You can see how these symbols connect to broader flowchart symbol standards and their practical applications.

How does ISO 5807 compare to other flowchart standards?

ISO 5807 is not the only standard that governs flowcharts. It's worth knowing how it fits alongside others:

ANSI X3.5 The American National Standards Institute version, which predates ISO 5807 and shares many of the same symbols. ISO 5807 was partly based on this.
BS 4058 The British Standard for data processing flowchart symbols. Very similar to ISO 5807.
BPMN (Business Process Model and Notation) A newer standard focused specifically on business processes. It's more detailed than ISO 5807 and includes swim lanes, event types, and gateway notations.
UML Activity Diagrams Used in software engineering, especially in object-oriented design. Different symbol set, different purpose, but solves a similar problem.

ISO 5807 is more general-purpose and data-processing-focused. BPMN is better for complex business workflows. UML is better for software architecture. The choice depends on your audience and purpose.

What mistakes do people make with flowchart symbols?

Even when people know the symbols exist, common errors creep in:

Using shapes inconsistently. A rectangle means "process" in one chart and "decision" in another on the same project. This destroys trust in the documentation.
Skipping the start and end terminals. Every flowchart needs a clear beginning and end. Without them, readers don't know where to start reading.
Cramming too much text inside a symbol. A process box should describe one step clearly. If it takes two sentences, you probably need to break it into multiple steps.
Not labeling decision branches. A diamond with two arrows coming out means nothing if the arrows don't say "Yes" and "No" (or whatever the condition produces).
Creating spaghetti flowcharts. When connectors cross too many lines, the chart becomes unreadable. Use off-page connectors or break the flowchart into sub-processes.
Mixing abstraction levels. One step says "Process order" (high-level) and the next says "Multiply quantity by unit price and add 8.5% tax" (very detailed). Keep consistent depth.

How do you get started using ISO 5807 in your work?

You don't need to buy the standard document to start using its principles. Here's a practical approach:

Pick a tool that supports standard symbols. Tools like Microsoft Visio, draw.io, Lucidchart, and even PowerPoint have ISO-compliant symbol libraries built in or available as templates.
Use the basic symbol set first. Process, decision, input/output, terminal, and flow lines cover most situations. Add document symbols and connectors as needed.
Add a symbol legend. If your audience might not know the standard, include a small legend on the chart showing what each shape means.
Label everything. Every symbol should have text inside or next to it. Every decision branch should be labeled with its condition result.
Test readability. Hand your flowchart to someone unfamiliar with the process. If they can follow it without asking you questions, you've done it right.
Reference the standard when required. In regulated or formal documentation, note that the flowchart follows ISO 5807 conventions. This adds credibility and makes auditing simpler.

Quick checklist before you publish a flowchart

Every flowchart has a labeled start and end terminal
Shapes are used consistently throughout the diagram
Decision symbols have all branches labeled
Text inside each symbol is short and clear (one action per box)
Flow lines show a logical direction and don't cross unnecessarily
A legend is included if the audience may not know the symbols
Sub-processes are referenced rather than inlined when they get complex
The chart follows ISO 5807 conventions if formal compliance is expected

Start by redrawing one existing flowchart using these rules. You'll immediately notice where confusion came from before and your team will thank you for it.