Iso 5807 Flowchart Notation Specifications and Design Standards Guide

If you've ever tried to create a flowchart for a team project and ended up with five people drawing the same process five completely different ways, you already know why ISO 5807 flowchart notation specifications exist. Without a shared standard, flowcharts become confusing, inconsistent, and nearly useless for communication. ISO 5807 solves this by defining exactly which symbols to use, how to connect them, and what each shape means so everyone reading your chart speaks the same visual language.

What Exactly Is ISO 5807?

ISO 5807 is an international 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 provides formal specifications for flowchart symbols, layout rules, and notation conventions used in data processing and software documentation.

The standard was first published in 1985 and has gone through revisions to stay relevant. It defines how to represent processes, decisions, input/output, data storage, and flow direction using standardized shapes and connectors. You can reference the official standard through the ISO catalog page for ISO 5807.

Why Does a Flowchart Notation Standard Matter?

Flowcharts are one of the oldest and most widely used tools for documenting processes, algorithms, and system designs. But a flowchart only works if the reader understands what each symbol means. Without a standard:

A rectangle might mean a process in one chart and a subroutine in another
Arrows might flow left-to-right in one diagram and top-to-bottom in another
Team members waste time asking "what does this shape mean?" instead of understanding the logic
Documentation becomes inconsistent across projects and departments

ISO 5807 removes that ambiguity. When everyone follows the same flowchart design standards, your diagrams become self-explanatory. New team members can read old documentation without guessing. Auditors can trace processes without confusion. And cross-functional teams can collaborate without misinterpretation.

What Symbols Does ISO 5807 Define?

The standard specifies a set of symbols organized by function. Here are the core categories:

Process and Operation Symbols

Rectangle Represents a process, action, or operation. This is the most common symbol in any flowchart.
Rectangle with double vertical lines Indicates a predefined process (a subroutine or module defined elsewhere).

Input and Output Symbols

Parallelogram Represents input or output of data (reading from a file, displaying a result).
Document symbol (rectangle with a wavy bottom line) Indicates a printed document or report.

Decision and Branching Symbols

Diamond Represents a decision point with two or more exit paths (yes/no, true/false).

Flow and Connector Symbols

Arrows Show the direction of flow between symbols.
Circle or small numbered connector Used to connect parts of a flowchart that span multiple pages or to avoid crossing lines.

Storage Symbols

Cylinder (open-ended rectangle with rounded bottom) Represents data stored on a magnetic disk or similar medium.

For a detailed visual breakdown of these shapes, see our ANSI standard flowchart symbols reference guide, which covers many of the same symbols from a complementary standard perspective.

How Is ISO 5807 Different From Other Flowchart Standards?

You might wonder how ISO 5807 relates to ANSI X3.5 (the American standard for flowchart symbols) or UML activity diagrams. Here are the key differences:

ISO 5807 vs. ANSI X3.5 These two standards share many of the same symbols because ISO 5807 was developed in close alignment with the ANSI standard. However, ISO 5807 is broader in scope, covering not just symbols but also documentation conventions, layout rules, and annotation practices.
ISO 5807 vs. UML UML activity diagrams serve a different purpose. They're designed specifically for object-oriented software modeling, while ISO 5807 focuses on general data processing documentation. If you're documenting a business process or algorithm flow, ISO 5807 is more appropriate. If you're modeling class interactions in software, UML fits better.
ISO 5807 vs. BPMN Business Process Model and Notation targets business process modeling with swim lanes, events, and gateways. ISO 5807 is simpler and more focused on technical processing logic.

When Should You Use ISO 5807 Notation?

ISO 5807 is most useful in specific situations:

Technical documentation When you need to document algorithms, data flows, or system processes for engineers and developers.
Quality management systems Organizations pursuing ISO 9001 certification often need standardized process documentation, and ISO 5807 notation helps meet those requirements.
Regulatory compliance Industries like healthcare, finance, and aerospace require clear, auditable process documentation. Using an internationally recognized standard makes audits smoother.
Cross-team collaboration When multiple teams or vendors work on the same system, a shared notation standard prevents misunderstandings.
Legacy system documentation Many older systems were documented using ISO 5807 conventions, so understanding the standard helps you read and maintain that documentation.

What Are the Layout and Convention Rules in ISO 5807?

Beyond symbols, ISO 5807 defines how flowcharts should be structured. These conventions are just as important as the shapes themselves:

Flow direction The standard convention is top-to-bottom and left-to-right. Arrows should always indicate the direction of flow clearly.
Connection points Lines should connect to symbols at specific points (top, bottom, or sides) to keep layouts clean and readable.
Off-page connectors When a flowchart spans multiple pages, numbered connectors and page references should be used to maintain continuity.
Annotations Additional text explanations can be placed near symbols, but should not clutter the diagram. The standard specifies where and how to add notes.
Start and end points Every flowchart should have clearly defined start and end terminators (typically ovals or rounded rectangles).

These conventions tie directly into proper flowchart coding conventions for software engineering, which extend these principles into programming documentation.

What Mistakes Do People Make With Flowchart Notation?

Even with a standard available, common errors show up in flowcharts regularly:

Using shapes inconsistently Drawing a process step as a rectangle in one place and an oval in another. Pick the right symbol and stick with it throughout the entire chart.
Missing decision outcomes A diamond decision symbol should always have clearly labeled exit paths (e.g., "Yes" and "No"). Unlabeled branches force the reader to guess.
Crossing flow lines When lines cross without a clear visual break, the reader can't tell which path connects to what. Use connectors or rearrange the layout to avoid this.
Overcrowding a single chart Trying to fit an entire complex system on one page creates a messy diagram. Break it into sub-charts connected by referenced process symbols.
Ignoring the audience A flowchart for a business stakeholder should look different from one for a backend developer. Know who will read the chart and adjust the level of detail accordingly.
No clear starting point Every flowchart needs a defined entry. Without it, the reader doesn't know where to begin.

How Do You Start Applying ISO 5807 in Your Work?

You don't need to memorize the entire standard to start using it. Here's a practical approach:

Learn the core symbols first Focus on the rectangle (process), diamond (decision), parallelogram (I/O), oval (terminator), and arrows (flow). These five cover most situations.
Follow flow direction rules Always flow top-to-bottom or left-to-right. Never make the reader backtrack visually.
Label everything clearly Each symbol should contain concise text. Decision branches should be labeled with their conditions.
Use a standard-compliant tool Diagramming tools like Microsoft Visio, draw.io, Lucidchart, and yEd all support ISO 5807 symbol libraries. Choose one and use its built-in shapes rather than drawing freehand.
Review against the standard Before finalizing a flowchart, check it against the ISO 5807 conventions. Look for inconsistent symbols, missing labels, and unclear flow paths.

Does Anyone Still Use ISO 5807 Today?

Yes, though the landscape has evolved. ISO 5807 remains relevant in several contexts:

Government and defense projects Many agencies still require documentation following ISO standards, including ISO 5807 for process flows.
Quality and compliance documentation Companies under ISO 9001, ISO 27001, or similar frameworks often reference ISO 5807 when creating process documentation.
Education Computer science and information systems courses still teach ISO 5807 notation as part of systems analysis and design curricula.
Legacy system maintenance Older systems documented with ISO 5807 conventions require knowledge of the standard to update or audit that documentation.

While newer notations like BPMN and UML have gained ground in specific domains, ISO 5807 remains the go-to standard for straightforward technical flowcharting.

Practical Checklist for ISO 5807-Compliant Flowcharts

Use this checklist before publishing any flowchart:

☐ Every flowchart has a clear start (terminator) and end (terminator)
☐ Process steps use rectangles no mixed shapes for the same function
☐ Decision points use diamonds with labeled exit paths
☐ Input/output uses parallelograms
☐ Flow direction is consistently top-to-bottom or left-to-right
☐ Flow lines never cross without visual separation
☐ Multi-page charts use numbered off-page connectors
☐ Each symbol contains concise, meaningful text
☐ The chart has been reviewed by at least one person who didn't create it
☐ The level of detail matches the intended audience

Start with one process you document frequently an onboarding workflow, a data processing pipeline, or an approval chain and rebuild it using ISO 5807 conventions. Once you see how much clearer the result is, applying the standard to everything else becomes an easy decision.