Factorio Logistics Controlling & Analysis

Contents 1. The Concept of the “Transparent Factory” 1.1 Why Offline Analysis? 1.2 Elements of Data Collection 1.3 Economic Evaluation of Production 1.4 Operating States and Accounting Logic 2. System Architecture and Registration 2.1 registered objects 2.2 Inserters as Transaction Units (“Accountants”) 3 Double-Entry Bookkeeping in Factory Ledger 3.1 Function of Double-Entry Bookkeeping 3.2 Four Virtual Inventory Accounts 4. The Material Flow in a Practical Example 5 Data Evaluation and Inventory 5.1 The Log Window – Central Workspace 5.2 Inventory View – Snapshot of System State 5.3 Transaction Window (TX) – Movements Over Time 5.4 Reset Dialog – Defined Restarts for Clean Analyses 5.5 Blueprint Analysis – Fixed Assets and Master Data Résumé Supplementary publications Appendix: Technical Details and System Configuration A.1 Memory Management and Ring Buffer Logic A.2 Optimization of Inventory Intervals A.3 Workflow for Excel-Based Evaluation A.4 File Paths and Security (Sandboxing) A.5 Multiplayer Capability A.6 Localization

The Concept of the “Transparent Factory”

The concept of the “Transparent Factory” aims to make the factory not only operable, but economically analyzable. Factory Ledger treats the factory as a logistical system whose state and dynamics are objectively measurable. Instead of relying on observations during live gameplay, the system enables structured offline analysis using external tools such as Excel. The factory thus becomes transparent: every relevant inventory position, movement, and investment is fully documented and traceable.

1.1 Why Offline Analysis?

A complex factory cannot be optimized reliably by intuition alone. Visual impressions are transient, system states change continuously, and cause–effect relationships often remain hidden. Offline analysis therefore pursues three clear objectives:

• Capture state: Which inventories actually exist in the factory at a defined point in time?
• Understand flow: How do materials move through the system?
• Evaluate cost: Which resources are bound in infrastructure and products?

Factory Ledger provides structured raw data for this purpose, explicitly intended for evaluation outside of Factorio. The system does not replace planning or decision-making. It provides a robust, data-driven basis for their assessment.

1.2 Elements of Data Collection

The system is based on three data types, each addressing a different analytical perspective. Only their combination enables a complete analysis of the factory.

Fixed assets capture the installed infrastructure, including machines and logistics objects, along with their cost structure. These data originate primarily from the blueprint analysis.

Working capital (inventories) describes the state of the factory at defined points in time. It answers which quantities currently reside in storages, machines, and virtual accounts.

Transactions (TX) document every individual movement of goods between objects and represent the temporal dynamics of the system.

To ensure unambiguous evaluation, all relevant objects must be identifiable. Factory Ledger therefore uses fixed identifiers that appear both in-game and in the exported data. These identifiers form the link between the graphical representation in Factorio and subsequent analysis in external tools. Without unambiguous identification, no reliable accounting is possible.

1.3 Economic Evaluation of Production

Factory Ledger evaluates production not through a fictional in-game currency, but directly at the source by quantifying real physical and logistical primary factors.

Instead of simulating abstract cost values, the system records all processes in concrete base units such as resource consumption, time requirements, energy usage, and spatial footprint. This objective data foundation makes factory processes directly comparable and economically assessable. It provides a precise basis that can be flexibly translated into individual cost models to weight efficiency according to user-defined priorities.

The system records in particular:

• Energy consumption: cumulative energy required for infrastructure and production
• Time consumption: throughput time from raw material to finished product
• Spatial footprint: physical space required by the infrastructure
• Raw materials: exact quantities of consumed base resources

Factory Ledger provides these data through blueprint analysis. They serve as the starting point for individual economic evaluations.

1.4 Operating States and Accounting Logic

Factory Ledger does not operate in continuous recording mode. Instead, it distinguishes clearly defined operating states that correspond to accounting periods in real-world systems.

• A simulation run (Run) defines a completed analysis interval. The run name marks a coherent accounting period and is explicitly set after a reset.
• The logging mechanism can be activated or deactivated explicitly. Only when logging is active does the system record material movements as transactions (TX).
• In addition, Factory Ledger strictly separates observation from measurement. Visible interfaces or open windows do not imply data collection. Only active logging produces accounting-relevant data.

This separation is essential for clean analyses. An explicit start, stop, and reset logic prevents mixed or contaminated datasets. Each record carries a unique ID and a timestamp, ensuring unambiguous attribution.

2. System Architecture and Registration TOP

For Factory Ledger to capture logistical processes, the physical objects of the factory must be explicitly known to the system. The system refers to this process as registration. Only registered objects participate in inventory snapshots, transaction logs, and subsequent offline analysis. The system consistently treats unregistered areas as the outside world or as an unresolved intermediate space.

2.1 registered objects

Factory Ledger strictly distinguishes between registered objects (known, identifiable, analyzable) and unregistered zones (black box, outside world, transit). The system does not register entire production lines. Instead, it selectively registers the relevant logistical nodes: storages, machines, and transfer interfaces. This approach reduces complexity and reflects the real-world logistical definition of system boundaries.

Registration occurs directly in the game world via hotkeys. After successful registration, a flying text appears above the object as visual confirmation. For machines and containers, the procedure is as follows: move the cursor over the object and press Shift + R. The system automatically assigns a unique identifier, such as C35 for a container or M33 for a machine. This identifier remains visible both in-game and in all exported data from that point onward.

To remove a registration, move the cursor over the registered object and press Shift + U. The system removes the object from all evaluations and consistently disconnects the associated data paths from the accounting logic.

Identifier conventions follow a fixed scheme:

• M-numbers (e.g., M33): registered machines

• C-numbers (e.g., C35): registered containers and storages (tanks use T-numbers)

• I-numbers (e.g., I156): registered inserters

Registered objects carry permanently visible markers. These markers serve two purposes. First, they provide orientation in-game by immediately indicating which objects are part of the analysis. Second, they ensure unambiguous identification within the system. Each identifier (M-, C-, or I-number) is globally unique. This separation is not cosmetic; it forms the foundation of the entire accounting logic.

2.2 Inserters as Transaction Units (“Accountants”)

Inserters occupy a central special role within the system. Neither machines nor containers generate transactions. Only inserters do. Every movement of goods is created by an inserter that removes an item from a source (TAKE) and transfers it to a destination (GIVE).

Inserters therefore act as the accounting agents of the system and operationally implement double-entry bookkeeping. Without active inserters, no transactions exist. This design choice is deliberate, as inserters directly represent the physical act of material transfer and are the only entities where accounting logic and material flow coincide unambiguously.

Inserters can be systemically active or inactive. Each inserter starts in an inactive state. The Factory Ledger system analyzes registered storages and machines and automatically activates adjacent inserters.

• Between two registered objects → internal logistics inserter (TAKE → GIVE)
• From unregistered to registered →
• goods receipt (RECEIVE) at the system boundary
• internal goods receipt (TRANSIT)
• From registered to unregistered →
• shipment (SHIP) at the system boundary
• internal goods issue (TRANSIT)
• Transfer to / input from unregistered production → Work in Progress (WIP)

This classification forms the basis for the color coding of inserters and for posting to the corresponding virtual inventory accounts. Using the hotkey Shift + R, a simple active inserter (yellow) switches to interface inserter mode (pink). Pressing Shift + R again switches it to WIP mode (green). Using Shift + U resets the inserter to a simple active inserter (yellow). Correct registration of these modes constitutes the operational interface between Factorio and the accounting system.

3 Double-Entry Bookkeeping in Factory Ledger TOP

In a real factory, not every transport path is fully transparent. Materials enter the system from the outside, move across conveyor belts, disappear into production machines, or leave the factory again. Factory Ledger reflects this reality by deliberately using virtual inventories in addition to registered objects.

These virtual inventories are not physical containers but accounting accounts. They ensure that the system records every material movement unambiguously, even when parts of the path cannot be registered.

3.1 Function of Double-Entry Bookkeeping

“RECEIVE” marks the entry of material from the outside world, “TRANSIT” bridges non-registrable transport paths, “WIP” represents ongoing production processes, and “SHIP” marks the exit of goods from the system. Together, these accounts form a closed logistical chain in which no material disappears uncontrolled or is counted twice.

This completeness is based on the consistent application of double-entry accounting logic to every material movement. Each transaction consists systemically of exactly two inseparable actions: a “TAKE”, which removes an item from a source, and a “GIVE”, which transfers the same item to a sink. Physically, the item is held by the inserter between these two actions; from an accounting perspective, however, it remains clearly assigned at all times. The system does not allow a state in which an item is assigned to neither a source nor a sink.

Between two registered objects, this logic results in a zero-sum operation. The TAKE reduces the inventory of the source, while the GIVE increases the inventory of the sink by exactly the same amount. This principle also applies to transitions across non-registered transport paths. In these cases, the system does not post TAKE or GIVE against a physical object, but against a virtual inventory account. Regardless of the specific path, material is always shifted from one account to another, and the overall balance remains consistent.

An exception is the virtual inventory WIP (Work in Progress). WIP does not represent a transfer, but a transformation. When material enters WIP, a TAKE removes it from a registered object and records it as “in progress”. From this point on, the zero-sum logic no longer applies, because the material does not reappear unchanged elsewhere. Production processes it and converts it into a different product, which only later re-enters inventory logic through a GIVE.

This is precisely why WIP is required. It makes visible that material has left inventory but is not yet available as a finished product. The system thus correctly represents that raw materials are bound and transformed before new inventories emerge. Without WIP, these processes would either appear as losses or result in impermissible double counting. By combining TAKE and GIVE postings with a deliberate suspension of the zero-sum logic in the case of WIP, a consistent model emerges in which every movement is traceable and every deviation explainable.

3.2 Four Virtual Inventory Accounts

Only machines, containers, and inserters can be registered. Everything outside the factory is not registrable. In addition, registering conveyor belts is not possible, or only with significant difficulty, due to Factorio’s internal implementation. Without virtual inventories, materials in these areas would disappear from the accounts or appear from nowhere.

Virtual inventory	Meaning
RECEIVE	Goods receipt from the outside world (inbound)
TRANSIT	Transport via non-registered paths
WIP	Material in production being processed
SHIP	Goods issue from the system (outbound)

Together, these accounts form a complete logistical chain from receipt to shipment.

RECEIVE – Goods Receipt

• RECEIVE represents the entry point of material into the registered system.
• When is RECEIVE posted? An inserter removes items from a non-registered source. The destination is a registered container or machine.
• Meaning for analysis: RECEIVE corresponds to classical goods receipt. Material increases inventory from an external source. Production costs arise outside the considered system.
  
  

TRANSIT – Logistical Intermediate Space

• TRANSIT is used when material passes through a transport path that cannot be resolved.
• Typical case: An inserter places items onto a conveyor belt, but conveyor belts are not registrable. The material is in motion but not stored.
• Posting logic:
• Transfer onto belt → posting to TRANSIT via GIVE.
• Removal from belt by the next inserter → removal from TRANSIT via TAKE.
• Meaning for analysis: TRANSIT makes visible quantities that are bound while in transit. This helps identify transport delays, congestion, and throughput problems. Without TRANSIT, this part of the system would remain invisible.
  
  

WIP – Work in Progress (Production)

• WIP represents material that is currently being processed, beyond direct control of material management. It makes visible how much material is currently “in production”.
• When is WIP posted? An inserter removes material from a registered inventory. The destination is a production area in which no individually registered containers or machines exist. The system deliberately ignores the internal production process and only records the handover.
• Meaning for analysis: WIP corresponds to the classical case of semi-finished goods entering production and being converted into finished products. This represents bound capital in non-available inventory.
  
  

SHIP – Shipment

• SHIP marks the exit of material from the registered system.
• When is SHIP posted? An inserter removes items from a registered object (TAKE). The destination is a non-registered sink (GIVE).
• Typical examples: Transfer to a shipping belt, feed into an external logistics network.
• Meaning for analysis: SHIP corresponds to goods issue to customers and sales and represents the completion of the logistical chain. Material posted here leaves the factory’s balance.

Virtual inventories are not alternative storage locations. They are deliberately coordinated components of a closed logistical model. They structure the material flow within the observed system and ensure that every movement of goods is recorded unambiguously and without contradiction.

4. The Material Flow in a Practical Example TOP

To illustrate the previously described logic of registration, inserter transactions, and virtual inventories in a comprehensible manner, the following section presents a concrete reference setup. The example uses the production of green circuits. This process combines simple transport operations with actual transformation processes and thus covers all relevant aspects of the accounting logic.

The material flow begins with the delivery of copper ore from the outside world. The ore reaches the factory via a non-registered transport path. Inserter I156 removes the ore (TAKE); systemically, the system assigns this removal to the virtual inventory RECEIVE. The inserter then places the ore into container C35 via GIVE, which functions as the input storage. With this step, the material has entered the system from an accounting perspective and is available as inventory.

From this input storage, inserter I157 removes the ore and feeds it into the registered furnace M33. Since both the inserter and the furnace are registered, this constitutes an internal transfer that operates as a zero-sum transaction. While the furnace takes over the material for processing, the ore inventory in the container decreases accordingly.

After smelting is complete, inserter I158 removes the resulting copper plates from the machine and places them into the output container C36. This step also remains entirely within the registered system and produces a balanced posting consisting of TAKE and GIVE. At this point, the original ore exists completely in the form of copper plates. Virtual inventories are not required here, as source and sink remain clearly identifiable at all times.

A small production setup: ore is delivered and enters the factory via the inbound inserters I156 and I170. After processing into basic products, the two interface inserters I179 and I182 transfer iron plates and cables into production as Work in Progress (WIP). Inserter I175 removes the finished green circuits from production, and the shipping inserter I176 sends them out of the system.

Subsequently, the copper plates leave the directly observable area. Inserter I158 removes the plates from container C36 and places them onto a non-registered conveyor belt. The TAKE occurs from a registered object, but no corresponding GIVE to a registered destination exists. The system therefore credits the transfer to the virtual inventory TRANSIT. The plates are now in transit, are not available, but remain visible from an accounting perspective.

At the end of the conveyor belt, inserter I166 picks up the plates and places them into the registered input buffer C39 of the cable production. This process forms the mirrored counterpart: the TAKE occurs from the virtual inventory TRANSIT, and the GIVE into C39. The transport is thus completed, the material is fully located within the system again, and the transit balance is reduced accordingly.

The system interprets the actual cable production as a value-added logistics service. At the output of the cable production, inserter I180 places the produced copper cables into the interface storage C39. From there, another inserter removes the cables (TAKE) and transfers them via GIVE onto a production conveyor belt. The cables are therefore in Work in Progress (WIP).

Iron ore follows an analogous process and is likewise smelted into iron plates. The system books these plates directly into WIP. From iron plates and copper cables, both in WIP, green circuits are produced in a non-registered machine. Inserter I175 removes the finished circuits from the production machine (TAKE) and places them into the interface storage C41 (GIVE).

The final section of the material flow is shipping. C41 also serves as the output storage. Inserter I176 removes the finished green circuits from the storage (TAKE) and transfers them to a non-registered outbound transport (GIVE). The TAKE reduces the inventory of the output storage, and the GIVE is assigned to the virtual inventory SHIP. With this step, the product permanently leaves the system and is recorded as goods issue in the accounts.

This practical example demonstrates that the entire material flow consists exclusively of TAKE and GIVE movements. Internal movements balance out, transport gaps are closed by the virtual inventory TRANSIT, production processes are correctly resolved via WIP, and external interfaces are cleanly separated through RECEIVE and SHIP. The example therefore serves not only as an illustration, but also as a reference model.

5 Data Evaluation and Inventory TOP

After the factory has been registered and the material flow logically defined, Factory Ledger provides a set of dialogs through which the user can access the recorded data. These dialogs are not intended for analysis itself, but for structured access to states, movements, and valuation information. They form the operational interface between the running simulation and subsequent offline evaluation.

The central element is the log window, from which all further functions are accessible. In addition, the system provides specialized dialogs for transactions, reset operations, and the analysis of fixed assets in the blueprint context.

5.1 The Log Window – Central Workspace

The user opens the log window with Shift + B. It serves as the central workspace of Factory Ledger and is deliberately designed as a single entry point. From here, both state data and extended functions are accessible. When opened, the window displays the results of the regularly performed inventories by default.

The log window is not a pure event log, but a controlled view of the currently relevant subset of stored data. During operation, it supports overview and plausibility checks of data collection. The full temporal depth of the data is deliberately not displayed in the window itself; it becomes accessible exclusively through export and subsequent offline analysis.

5.2 Inventory View – Snapshot of System State

In the default view of the log window, Factory Ledger displays inventory snapshots. The system generates these inventories automatically at fixed intervals. Each inventory represents a complete snapshot of the system state.

The inventory records all registered containers, the state of machines, and the balances of the virtual inventory accounts. It therefore always describes the state of the factory at a clearly defined point in time. It answers which quantities are bound at which locations, but not how they arrived there. Especially in combination with the virtual inventories, this view provides a complete overview of the material and capital currently bound within the system.

5.3 Transaction Window (TX) – Movements Over Time

While the inventory describes the static state, the transaction window represents the temporal dynamics of the system. The user opens it via the TX button in the log window. The window lists all recorded movements of goods in chronological order and thus makes the progression of material flows traceable.

Each row in the transaction window corresponds exactly to one movement performed by a registered inserter. It documents the involved objects and the moved item. The window therefore serves to observe the ongoing material flow and to check the plausibility of logistical interfaces. The user can immediately see whether inserters operate as intended and whether TAKE and GIVE relations function correctly.

The transaction window is explicitly not an analysis tool. It acts as a view into ongoing operations. Evaluation of longer periods and complex relationships is performed exclusively through export and subsequent offline analysis.

5.4 Reset Dialog – Defined Restarts for Clean Analyses

For reliable evaluations, it is often necessary to return Factory Ledger to a defined initial state. For this purpose, the system provides a dedicated reset dialog. The user accesses it directly from the log window and can use it to restart data collection, accounting periods, and analysis intervals in a controlled manner.

A reset does not delete the physical factory, but selectively resets the recorded data. Inventories and transactions can be removed entirely so that a new accounting period begins. Items in containers or machines that should be preserved can be marked as protected beforehand. Likewise, the lists of registered objects (containers, machines, protected) can be reset selectively.

In this way, the system creates reproducible starting conditions, for example to analyze the ramp-up of a production line in a controlled manner. Reset is therefore not an emergency tool, but a deliberately used instrument for structuring measurement phases and comparing different scenarios.

5.5 Blueprint Analysis – Access to Fixed Assets and Master Data

In addition to ongoing operational data, Factory Ledger provides an additional evaluation function within the Blueprint dialog of Factorio. Within this dialog, a dedicated control allows the user to trigger an analysis of the selected setup. This analysis exposes fixed assets and the associated master data independently of the current operational state.

This analysis generates neither logs nor transactions, but provides a pure snapshot of fixed assets. It lists both the required infrastructure and a complete list of the items used. On this basis, master data can be derived, cost models can be built, or different layouts can be systematically compared. The blueprint analysis thus complements ongoing accounting with a static evaluation of the installed base.

Résumé TOP

Factory Ledger is an instrument for structured measurement of processes in a Factorio factory. Through the clear separation of registration, material flow logic, state snapshots, and transactions, the factory becomes a transparent logistical system. Inventories, movements, and investments are unambiguously identifiable and integrated into a consistent accounting logic.

This document describes the underlying system concepts and the operation of Factory Ledger. Evaluation of the generated data is not part of this guide. It is performed outside of Factorio, typically using Excel, and is covered in separate publications. These further analyses are part of accompanying teaching modules and build directly on the functions described here.

Supplementary publications

• Using Factorio as a Logistics Simulation: Why I Built a Factory Logging & Analysis Mod
• A Factorio Case Study in Industrial Efficiency: Storyline - Context of this Case Study is Goldratts Theory of Constraints.
• Accounting Logic Must Not Follow Physics Too Closely: Physics ≠ Accounting ≠ Software, that´s not easy
• Get Factory Ledger in the factorio mod portal and on GitHub

Appendix: Technical Details and System Configuration TOP

This appendix supplements the description of Factory Ledger with technical notes on internal data management and on the appropriate configuration of key parameters for short-term and long-term analyses. These aspects are not required for a basic understanding of the system. They become relevant once larger data volumes are generated or multiple analysis cycles are compared.

A.1 Memory Management and Ring Buffer Logic

To limit memory consumption within the running Factorio simulation, Factory Ledger uses a ring buffer structure for transactions. Instead of accumulating events indefinitely in memory, the system defines a fixed maximum number of transactions that can be retained at any given time. This capacity is configured via the mod settings at the start of the simulation and can be adjusted to match the desired analytical resolution.

Once the defined capacity is reached, the ring buffer gradually overwrites the oldest entries with new transactions. This keeps memory usage constant regardless of how long the simulation runs. To still enable consistent external evaluation, the system assigns each transaction a continuous, unique ID. This ID is not reset, even when older entries in the buffer are overwritten. As a result, transaction export files from different points in time can later be merged seamlessly without duplicates or ambiguities.

A.2 Optimization of Inventory Intervals

Factory Ledger inventories are based on periodic snapshots of the system state. The choice of the inventory interval directly affects both the volume of generated data and the system load during simulation. The interval can be configured via the settings and should be chosen deliberately.

A long interval reduces the number of generated inventory records and conserves memory and export volume. In this case, state changes between two inventories must be reconstructed more heavily from transaction data. A short interval, by contrast, significantly increases temporal resolution by generating very frequent complete inventories. This enables detailed analyses but results in large data volumes and increased computational effort, since every inventory requires reading all registered containers and machines.

In practice, the choice of the inventory interval always represents a trade-off between data density and system load.

A.3 Workflow for Excel-Based Evaluation

The export files generated by Factory Ledger are specifically designed for further processing in spreadsheet applications such as Excel. Exports use the CSV format with a semicolon as the field separator, which allows smooth import especially in German-language Excel environments.

Many values are output in the format label=value, for example to encode machine states or metadata. This structure allows straightforward processing using standard Excel functions or via the “Text to Columns” feature. Inventory and transaction data follow a consistent structure, allowing timestamps, object identifiers, and status information to be directly related. This makes it possible, for example, to correlate inventory changes with machine states or transaction density.

A.4 File Paths and Security (Sandboxing)

Due to Factorio’s security architecture, extensions are not permitted unrestricted access to the file system. Factory Ledger therefore writes all exports exclusively to the designated script-output directory.

In a standard Windows installation, this directory resides in the Factorio user directory. In portable or ZIP-based installations, the script-output directory is located directly in the write directory of the respective installation. File names include both a type identifier, for example for inventory or transaction data, and a timestamp. This prevents existing files from being unintentionally overwritten when multiple exports are performed.

A.5 Multiplayer Capability

Factory Ledger is designed to operate stably and consistently in a multiplayer environment. System-wide, there is always a single shared registration list and a central data set for inventories and transactions. The system records all actions regardless of which player triggers them.

The current version deliberately does not separate data by individual players. The analysis treats the factory as a shared logistical unit. This approach supports cooperative scenarios in which multiple players work together on a factory and use the same data basis for analysis. Player-specific data breakdowns are not provided and are reserved for potential future extensions.

A.6 Localization

Factorio uses English as the default language for extensions. Factory Ledger is therefore fully localized in English. In addition, a complete German localization is available, covering all dialogs, labels, and outputs. The language is selected automatically based on the Factorio language settings. Both language versions are identical in content, ensuring that outputs and export data remain consistent regardless of the selected language.

TOP

Blog: , Seite:
Version: 1.4 April 2025, Kontakt: E-Mail Martin Wölker
Pirmasens, Germany, 2018-, ausgelesen am: , Licence CC BY