Accounts resources and units

Section titled “Accounts resources and units”

This page explains race treasury income, civilian company receipts and the records that preserve them. It covers worker taxes, financial centres, trade goods and delivery contracts, civilian mining, fuel sales, recovery and transfers, together with category IDs, balance adjustments, history and what a save keeps. Installation recipes, category descriptions and DIM_WealthUse.Income flags are loaded from the game database. They are game data, not universal rules.

Gross delivery revenue, a company’s net receipt, race tax income and the race’s final balance change are different quantities. Race wealth also differs from minerals, fuel and other physical stockpiles. A transaction row records one credit made by one game activity. It is not a calculation of total operating profit, and the game saves the treasury separately from its transaction rows.

The race treasury is FCT_Race.WealthPoints, a balance that can hold fractions and starts at 0 on a new race record. FCT_Race.StartingWealth and FCT_Race.AnnualWealth are separate values. The starting wealth value is not added again each cycle. The annual wealth value is the calculated annual flow from workforce taxes and financial centres, and the game uses it for debt effects and for the treasury ceiling. A civilian company’s balance (FCT_ShippingLines.WealthBalance) belongs to the company and is not part of the race treasury. Mineral, fuel, MSP, ordnance and cargo stockpiles are separate ledgers of physical resources.

Quantity Meaning
Race treasury (FCT_Race.WealthPoints) Current race-wide treasury. Debt is a negative balance.
Annual workforce wealth, annual financial wealth and annual wealth (FCT_Race.AnnualWealth) Recalculated annual tax and finance rates. Other receipts are excluded.
Starting wealth (FCT_Race.StartingWealth) A separately saved value. It is not itself the mechanism that collects recurring income.
Company balance (FCT_ShippingLines.WealthBalance) Company funds, separate from the owning race’s treasury.
Treasury transactions (FCT_WealthData) and company receipts (FCT_ShippingWealthData) Recorded treasury transactions versus recorded company receipts, with different columns and retention.
Balance snapshots (FCT_WealthHistory) A time and balance sample, distinct from a transaction.

Population amounts and workers are in millions. Passenger and colonist amounts in delivery fares are individual people. Elapsed years use 31,536,000 seconds per year, and delivery distance is measured in billions of kilometres. Build points, minerals, fuel litres, maintenance supplies and finished items remain separate resources.

For detailed production debits and the recovery of physical resources, see Player race production mechanics. This page concentrates on the money those operations record.

Population taxes financial centres and debt

Section titled “Population taxes financial centres and debt”

Population tax and financial-centre income

Section titled “Population tax and financial-centre income”

Each population calculates an annual wealth rate. This calculation does not credit the treasury by itself. The taxable workforce is the workers of the population’s own shipyards that are not carried aboard a ship, plus, for each installation type whose DIM_PlanetaryInstallation.TaxableWorkers flag is set, installed amount x Workers for that type. It is not all citizens and not every installation worker. Population and workforce quantities are in millions. A naval shipyard employs slipways x capacity x 0.00025 million workers, with the capacity in tons. Other shipyards use 0.000025. Shipyards carried aboard ships are excluded.

Define the population wealth multiplier W:

W = political status WealthMod x race wealth creation rate x radiation production modifier x colony governor wealth creation bonus x sector governor quarter-strength wealth creation multiplier. The race wealth creation rate is FCT_Race.WealthCreationRate, and the political status, colony governor and sector governor terms are described on their own pages.

When unrest (FCT_Population.UnrestPoints) is above 0, W is also multiplied by stability. An absent colony governor or sector governor contributes 1. Wealth Creation is a percentage bonus (DIM_CommanderBonusType ID 20), so a governor without it also contributes 1. The sector governor’s quarter multiplier is 1 + (bonus value - 1) / 4, and a sector governor without the bonus contributes 1. This wealth formula does not include the species production rate modifier (ProductionRateModifier) or the race economic production modifier (FCT_Race.EconomicProdModifier). Stability applies only when unrest is positive. The political status catalogue lists the WealthMod values.

Annual income value Exact formula
Workforce wealth production taxable workforce x efficiency x W
Financial wealth production financial capacity x efficiency x W
Total wealth production workforce + financial

Financial capacity is the sum over the population’s installations of installed amount x DIM_PlanetaryInstallation.FinancialProductionValue. Unlike the annual construction capacity, this financial capacity is not truncated to a whole number. Cost, Workers, TaxableWorkers and FinancialProductionValue are installation data that the game reads from DIM_PlanetaryInstallation when a game is loaded.

Efficiency (FCT_Population.Efficiency) is 1 unless the required manufacturing workers exceed the available manufacturing population. Then it is max(0, available / required). Worker demand includes the worker requirement of every installation, taxable or not, and the population’s shipyards. The radiation production modifier is max(0, 1 - FCT_SystemBody.RadiationLevel / 10,000). Stability is 1 - unrest / 100, after unrest is clamped to 0 to 99. The workforce, radiation and stability inputs are shared with production.

The race wealth creation rate defaults to 100. Researching a racial wealth creation technology replaces it with that technology’s FCT_TechSystem.AdditionalInfo value. Take one million taxable workers, efficiency 1, all other modifiers 1 and rate 100. That population produces 100 wealth per year. Ten financial capacity at the same modifiers produces 1000 per year. A +20% governor and a +20% sector governor give 1.2 x 1.05 = 1.26, not 1.4. These examples are derived from the formulas. They are not fixed installation outputs from the catalogue.

Each race sums every owned population’s workforce, financial and total values into its annual workforce wealth, annual financial wealth and annual wealth. Annual wealth excludes shipping taxes, mining taxes, scrap, looting and ruin recovery. The same step sets the race’s debt-based economic production modifier (FCT_Race.EconomicProdModifier). A treasury of 0 or more gives 1. Debt with an annual income of 0 gives .01. Otherwise the modifier is max(.01, 1 - |treasury| / annual wealth). W omits the economic production modifier, so this debt penalty does not directly reduce the tax and financial income formulas. It applies to production capacity instead.

Local financial installation definitions

Section titled “Local financial installation definitions”

The installation catalogue in the game database as shipped contains two definitions with a positive FinancialProductionValue:

ID and installation FinancialProductionValue Workers (millions) TaxableWorkers Unit cost BP Annual wealth at W = 100 and efficiency 1
25 Financial Centre 0.25 0.05 1 120 25 finance + 5 worker tax = 30 total
38 Conventional Industry 0.025 0.05 0 240 2.5 finance, no worker tax from its workers

These are catalogue values. The game does not enforce them as limits, and a modified game’s definitions can differ. Conventional Industry still contributes to worker demand even though its workers are not taxable.

Collection cadence and treasury ceiling

Section titled “Collection cadence and treasury ceiling”

During each construction cycle, the strategic update first refreshes each colony’s environment, workforce and efficiency. Then, for every standard race (FCT_Race.SpecialNPRID 0), which covers player races and ordinary NPRs, it calculates annual income. It records elapsed years x annual workforce wealth under Worker Taxes (ID 11) and elapsed years x annual financial wealth under Financial Centres (ID 39). These formulas apply no rounding. A zero amount is still recorded.

Immediately afterward, if the treasury is above 2 x annual wealth, the game sets the treasury to exactly 2 x annual wealth. This can discard money already held and income just recorded. It is a ceiling on the stock, based on annual tax and financial income, not a cap on each transaction. It is not logged as an expense. With an annual income of 0, a positive treasury is reset to 0 at that point. The economic production modifier was calculated before that cycle’s tax credits and cap.

Ship Sorium harvesting runs before the colony recalculation, the tax collection and the cap, so its income can be clipped by the same cycle’s ceiling. Civilian mining tax is recorded in the later population production step, and ruin recovery runs later still. Those credits can therefore take the treasury above the ceiling until the next collection cycle. Shipping delivery receipts arise when an unload succeeds, not as an annual tax credit.

Trade goods delivery taxes and civilian contracts

Section titled “Trade goods delivery taxes and civilian contracts”

Trade goods generate transport opportunities, not direct annual cash

Section titled “Trade goods generate transport opportunities, not direct annual cash”

A population creates and updates trade balances (FCT_PopTradeBalance) only for the trade goods whose population threshold (DIM_TradeGoods.PopRequired) is strictly below the population’s total population. When a commodity balance is created, its production rate (FCT_PopTradeBalance.ProductionRate) is drawn at random. Three times in four it is 0 to 1 in steps of .1. Otherwise it is a whole number from 2 to 5. The manufacturing fraction is the population left after the agriculture, environmental and service sectors, divided by the total population. Define B = total population x (W / 100) x .5 x manufacturing fraction. Annual commodity production is production rate x B, and annual consumption is B. The balance gains the difference times elapsed years, and it is capped at one year’s net surplus or deficit. This step records no wealth for the goods produced. Wealth arrives through the delivery taxes and company fares described below.

A new infrastructure balance starts with a production rate of 2 and produces 2B per year. If the infrastructure shortfall is positive, the entire balance becomes Infrastructure installations and the balance resets to 0. Otherwise the stock is capped at one year’s output. The target is the population’s maximum required infrastructure, or 1.25 times that for a colonist destination. This is installation output, not race wealth. A new artefact balance starts with a production rate of 0. On a body without ruins the artefact balance consumes B per year with no lower limit, so the deficit grows without end. Only an upper cap applies to that balance. Artefacts recovered from ruins instead become trade stock that can earn delivery revenue.

Civilian shipping: race taxes versus company revenue

Section titled “Civilian shipping: race taxes versus company revenue”

A company’s balance is separate from the race treasury. Recording a company receipt creates a shipping record (FCT_ShippingWealthData) and adds its amount to the company’s balance. Race taxes are separate treasury credits. The delivery formulas use one distance marker per ship, the load distance, which holds the ship’s distance travelled at its last load or revenue calculation. There is no trip distance for each cargo item.

Let d = (distance travelled - load distance) / 1,000,000,000, in billions of km, and t = race delivery tax fraction (FCT_Race.ShippingLineTax). Each successful revenue calculation resets the load distance to the ship’s current distance travelled. A successful load onto a company ship also sets that marker. With gross revenue G, the tax is G x t and a player company receives G - tax. An NPR company’s revenue is also multiplied by .5 after the tax is computed and subtracted. The race tax is not halved.

Delivery Gross wealth G Race income category Company receipt and state cost
Trade good cargo amount x .375 x d Tax on Shipping Trade Goods (32) Company receives G - tax. The race pays nothing on this delivery.
Specific installation cargo whole current matching cargo points x .00015 x d Tax on Shipping Trade Goods (32) Company receives G - tax. The race pays that same company receipt as Civilian Contracts (44).
Passenger liner colonists individual passenger count x .006 x d Tax on Passenger Liners (43) Company receives G - tax. The race pays nothing on this delivery.
Colony ship colonists individual colonist count x .00015 x d Tax on Shipping Colonists (34) Company receives G - tax. The race pays nothing on this delivery.

The constant rates are wealth per cargo unit per billion km. Installation cargo points equal DIM_PlanetaryInstallation.CargoPoints x cargo amount. The database description of category 44 is Civilian Contracts.

Delivery gates and accounting details:

  • Installation and colonist revenue is calculated only when the ship belongs to a company. Trade-good unloading computes the tax for any ship and records the company receipt only when the net revenue is positive. It does not first check that the ship belongs to a company. For a ship outside any company with positive net revenue, the game shows error code 2788 (Function #2788) and the trade-good unload ends there, after any tax credit and before the cargo reaches the population.
  • A cargo shuttle transfer multiplier of zero prevents these unloads and the income tied to them. Colonists must match the destination species. Colonists from a neutral empire cannot unload in the same system in which they loaded. Cargo amounts are individual people, converted to millions only when added to the population.
  • Specific installation delivery bills the whole current matching cargo entry before it limits the actual unloading to the remaining unload quantity. Unloading every installation without a chosen type instead adds all entries, clears the cargo and stops before any revenue is calculated. The charge is therefore not a fixed amount per installation actually unloaded in every unload mode.
  • Each colonist entry that unloads resets the same load distance. Later entries in the same unload can therefore see zero distance without travel in between. Other cargo deliveries also use and reset that marker.
  • Trade-good race tax and company revenue are each recorded only when above 0. Installation, liner and colony ship deliveries record their amounts without that test, and they do not clamp the tax rate or negative results at that point. These are separate rules for each kind of cargo.
  • Ordinary delivery receipts are stored with the contract flag (FCT_ShippingWealthData.Contract) off, including the installation delivery that separately charges Civilian Contracts (44). The transaction category and the shipping record’s contract flag therefore do not mean the same thing.

For a player installation delivery with gross G and tax fraction t, the race receives Gt and pays G(1 - t), so its net treasury change is G(2t - 1). At t = .2, that is -.6G, while the company receives .8G. This is a tax credit paired with a state contract expense, not a net profit equal to the tax row. Trade-good and colonist fare deliveries carry no matching state payment.

The delivery tax rate is stored as a fraction, so .2 means 20%. The “Edit Tax Rate” button in the Economics window accepts a percentage, divides it by 100 and clamps only negative results to zero. It has no upper clamp, so values above 100% can reach the delivery arithmetic. Those values can produce negative company receipts or contract expenses on the deliveries without positive-value tests. A saved race loads FCT_Race.ShippingLineTax on its own. A standard or minor NPR is created with a tax fraction of 0.5. This NPR start value is separate from any player tax default.

Worked trade example. 100 trade-good units carried 2 billion km produce 75 gross wealth. At tax fraction .2, the race receives 15 and a player company 60. Delivering 10 individuals on a colony ship over 2 billion km instead produces .003 gross. A passenger liner with the same 10 people and distance produces .12 gross. These examples apply the game’s units directly. Cargo people are not measured in millions for the fare.

A new company starts with a balance of 2000 for a player race and 4,000 for an NPR, and creating it does not debit the race. The game can also calculate an available dividend as max(0, min((ship cost + company wealth) / 10, company wealth - 1000)), and 0 when the company has no ship cost. This is a calculation only. It moves no money to the treasury, and nothing in play uses it.

The Civilian Shipping Lines Active game option (FCT_Game.CivilianShippingLinesActive) controls new-company and new-ship processing, and repair processing for existing companies runs under the same option. New-ship construction requires that the race can support civilian shipping and owns at least one shipyard. A race can support civilian shipping when it has researched the baseline nuclear radioisotope engine technology and owns at least two populations with a positive surface population. These are support and creation gates, not extra tests inside each delivery. The civilian rules page lists the option.

Civilian mining and fuel receipts

Section titled “Civilian mining and fuel receipts”

Civilian mining taxation versus purchasing minerals

Section titled “Civilian mining taxation versus purchasing minerals”

During population mining, when civilian mining potential is positive and the body has at least one mineral deposit entry, a player population set to Tax Civilian Mining in the Economics window (FCT_Population.PurchaseCivilianMinerals 0) records whole-number civilian mining complex count x 125 x elapsed years as wealth under Tax on Civilian Mining (35). The race receives only its non-civilian share of the mineral output. With Purchase Minerals selected (PurchaseCivilianMinerals 1) the population instead pays complex count x 250 x elapsed years under Purchase of Civilian Minerals (36). It then receives the civilian mineral share locally or sends it straight to the selected mass-driver destination. No company balance is involved.

The tax or purchase amount depends on complex count and time, not on tons actually mined or on mineral accessibility. When the body has no deposits left, the civilian complexes disband instead of paying tax. The production step runs mining only when total mining production is above 0. NPR civilian mining takes the minerals locally without the player’s tax or purchase wealth entries.

Civilian fuel harvesting and overflow sale income

Section titled “Civilian fuel harvesting and overflow sale income”

Sorium harvesting considers ships with an undamaged Sorium harvester and fuel below tank capacity at a gas giant or superjovian that holds Sorium. Potential harvest uses undamaged harvester modules x race fuel production rate (FCT_Race.FuelProduction), the ship commander’s mining bonus, the crew fraction when the ship is understaffed, the administrative command’s mining multiplier, elapsed years and deposit accessibility. The potential fuel converts to Sorium at 2,000 litres per Sorium unit and is capped by the deposit.

If the potential fuel exceeds the ship’s empty tank space and the ship belongs to a company, the excess fuel earns company wealth of excess litres x .0001. The race receives one fifth of that amount under Tax on Civilian Fuel (47). This is a fixed 20% share, independent of the race delivery tax fraction. The company still receives the full calculated sale wealth, not the sale wealth minus the race share.

Deposit accounting anomaly. After recording sale income for the excess output, the game reduces the harvested Sorium to empty tank capacity / 2000 and debits only that reduced amount from the deposit. The excess output sold for wealth is not deducted from the deposit’s Sorium. Ships that are already full are excluded at the start and receive no overflow sale. Government ships outside any company simply cap retained output and earn no income.

Example. A potential of 2000L with 500L of tank space yields 1500L excess, company .15 wealth and race .03 wealth. The ship keeps 500L, and the deposit loses only .25 Sorium. A recorded fuel sale has no origin or destination population and has its fuel flag (FCT_ShippingWealthData.Fuel) set. No other ordinary civilian fuel sale earns wealth in play. These receipts are distinct from ordinary fuel transfers. The Sorium harvesters section covers the fuel side.

Recovery transfers and initial funding

Section titled “Recovery transfers and initial funding”

Scrap and recovered wealth

Section titled “Scrap and recovered wealth”

Scrapping gives immediate income under Scrap (26), not annual income. These amounts use the object’s recorded unit cost, without worker, radiation, commander or distance modifiers:

Scrap subject Wealth recovered
Population stored component component amount x component cost x .3
Ship stored component cargo all matching cargo amount x component cost x .3
Ground formation element units x ground class cost x .3
Installations requested scrap quantity x installation cost x .3
Ordnance stockpile missile quantity x missile cost x .25

Minerals are recovered at the same 30% and 25% scale of each mineral cost. Ordnance also returns 100% of the missile’s defined fuel. The scrap recovery section covers the minerals.

Scrapping stored components or ordnance removes the scrapped stock entry. Scrapping installations or ground elements only credits the resources by itself. The installation scrap action in the Economics window limits the quantity to the stock held and separately subtracts or removes the installations. Shipyard scrapping recovers intact components, ordnance, fuel and MSP, not a direct cash award for the whole ship. Cash can come later from scrapping the recovered components. Salvaged material and technology are likewise distinct from the cash categories on this page.

Ruin wealth recovery is active, under Recovered from Ruins (51). The recovery step visits populations on bodies with positive FCT_SystemBody.AbandonedFactories whose ruin race the population’s race already knows. Eligible formation elements belong to formations stationed there with FCT_GroundUnitFormation.DoNotRecover 0, and they have a positive effective construction rating. For each element, the recovery chance is morale x formation commander xenoarchaeology multiplier x 500 x elapsed years x effective construction rating, with a multiplier of 1 without a commander. The formation commander is described on its own page. The recovery succeeds when a d10000 roll is strictly below that chance. Each success consumes one abandoned factory and selects weighted loot. Once the abandoned factories are exhausted, later elements make no attempt. The construction recovery rules cover the formations.

Wealth loot has weight 10 among the current sum of all loot weights. A selected wealth result gives 200 x sum of five d10 rolls, 1000 to 10000 wealth in steps of 200, with an expected value of 5,500. It credits the recovering population’s race immediately. No production stock or treasury payment is consumed. Chance modifiers affect whether a loot roll happens, not this wealth quantity. The loot table lists the other results.

Conquest, independence and initial funding

Section titled “Conquest, independence and initial funding”

A control transfer can move wealth when the population’s original race differs from the new owner, the transfer applies wealth looting, the current owner is a standard race and its treasury is above 0. The wealth taken is old treasury x captured population surface population / old race total surface population, before ownership changes. The new owner records Looted from Conquered Population (30). The old owner records Lost due to Conquered Population (31). This redistributes held wealth. It is not a fixed reward per population, and it creates no treasury from nothing. No separate hostile-contact check applies, despite the wording of the event message.

Granting independence to a population similarly computes old treasury x departing population share of surface population. The game records that amount as the new race’s Starting Wealth (8) and debits the old race under Lost to Independence (52). Unlike conquest, the share has no positive-treasury condition, so debt can transfer as a negative amount. The way the new race is copied also affects transaction history, described in All direct treasury balance writers and transfers.

When the independent race is a standard NPR and does not start at the Pre-Industrial level, its delivery tax fraction (FCT_Race.ShippingLineTax) is set to 0.5 during its civilian shipping setup.

In the race set-up path described here, the race receives one year of its homeworld’s wealth output as Starting Wealth (8). This initial credit is distinct from ongoing collection and from civilian company starting balances. The race creation page covers the other starting stocks.

The treasury income credit adds its amount directly. It is not limited by the current treasury and does not turn a negative amount into a nonnegative receipt. Affordability and validation depend on the activity that records the credit. Retired labels such as Trade Income (9) and Tariff Income (10), and the active Tax on Exports (33), do not by themselves create a revenue stream. The category table below shows which categories are unused.

Income categories and what credits them

Section titled “Income categories and what credits them”

The game’s rules refer to each category by its numeric ID. The descriptions and Income flags below are exact values from DIM_WealthUse in the game database as shipped, listed with this query:

SELECT WealthUseID, Description, Income, DisplayOrder FROM DIM_WealthUse ORDER BY WealthUseID

The descriptions keep the database’s words and capitalisation. The expense description at ID 31 has trailing whitespace in the database. The game loads every row of this table when a game is loaded.

The table lists every category whose Income flag is set. A retired category is a row the game still loads but that no rule can use. “No activity credits it” means no game activity creates that category’s transactions. A saved or externally supplied transaction can still refer to its row.

ID Description Status What changes the balance
8 Starting Wealth Active Initial homeworld annual wealth grant, and the independence allocation.
9 Trade Income Retired No activity credits it.
10 Tariff Income Retired No activity credits it.
11 Worker Taxes Active Strategic cycle, elapsed years x annual workforce wealth.
15 Sale of Minerals Retired No activity credits it.
17 Sale of Installations Retired No activity credits it. Scrapping uses ID 26.
19 Sale of Ordnance Retired No activity credits it. Scrapping uses ID 26.
20 Sale of Fighters Retired No activity credits it.
22 Sale of Technology Retired No activity credits it.
24 Sale of Ships Retired No activity credits it.
26 Scrap Active Colony component, formation element, installation and ordnance scrap, and scrap of components carried aboard a ship.
30 Looted from Conquered Population Active Treasury share taken from the conquered population’s current owner before the transfer.
32 Tax on Shipping Trade Goods Active Both trade-good unloading and civilian installation delivery.
33 Tax on Exports Active No activity credits it.
34 Tax on Shipping Colonists Active Colony ship colonist delivery.
35 Tax on Civilian Mining Active Civilian mining complex taxation.
38 Foreign Aid Received Retired No activity credits it.
39 Financial Centres Active Strategic cycle, elapsed years x annual financial wealth.
43 Tax on Passenger Liners Active Liner colonist delivery.
47 Tax on Civilian Fuel Active Company harvester overflow, excess fuel sale amount / 5.
51 Recovered from Ruins Active Ruin wealth loot, sum of five d10 rolls x 200.
52 Lost to Independence Active An actual treasury expense despite Income 1 in the database.

The complete set of active expense categories is:

  • 1 Ground Unit Maintenance, 2 Ordnance Production, 3 Fighter Production, 4 Installation Construction, 5 Shipbuilding, 6 Ground Unit Training and 7 Research.
  • 27 Shipyard Modifications, 28 Maintenance Supplies, 31 Lost due to Conquered Population and 36 Purchase of Civilian Minerals.
  • 40 Ship Component Production, 41 PDC-related Construction, 44 Civilian Contracts, 45 Orbital Habitat Construction, 49 Ship Repairs and 50 Ship Refits.

All of them have Income 0 in the game database as shipped. ID 52 also debits the treasury but is classified as income. An active category does not by itself prove that some activity records it.

The other expense rows of DIM_WealthUse are retired. They are 12 Maintenance Facility Operation, 14 Purchase of Minerals, 16 Purchase of Installations, 18 Purchase of Ordnance, 21 Purchase of Fighters, 23 Purchase of Technology, 25 Purchase of Ships, 29 Purchase of Civilian Ships, 37 Foreign Aid, 42 Shipping Line Subsidy, 46 Purchase of Civilian Fuel and 48 Maintenance Facility Production. No activity changes the treasury through these rows. ID 13 is absent from the table as shipped.

Treasury transactions and unlogged adjustments

Section titled “Treasury transactions and unlogged adjustments”

How treasury transactions are recorded

Section titled “How treasury transactions are recorded”

A treasury income credit adds its amount to the treasury, and an expense debit subtracts it. Both then append a transaction with the amount, the category, the race and the current game time (FCT_WealthData columns Amount, UseID, RaceID and TimeUsed). The expense amount is stored as given, not negated. A transaction has no separate income or expense flag, no balance-after value, no transaction ID, and no population, ship or counterparty.

The credit and the debit do not test affordability, NPR status, zero or negative amounts, or event-logging settings. A zero amount creates a zero row. Negative income reduces the balance, and a negative expense increases it. Each activity decides whether to record anything. For example, trade-good unloading records only positive tax and revenue, whereas the worker and financial credits and the colonist and installation deliveries can append zero amounts. A missing category is not rejected. The balance changes before the row is built and appended. If building the row fails, the game shows error code 2459 for an expense or 2460 for income (Function #2459, Function #2460), and that recording ends with the balance already changed. These are individual records, not an atomic double-entry system.

Category classification comes from the database. When a game is loaded, the game reads every DIM_WealthUse row, including the IDs of retired categories, and loads WealthUseID, DisplayOrder, Income and Description. Whether an activity credits or debits determines the actual direction of the balance change. The loaded Income flag determines which summary list shows the amount. Nothing checks that the two agree. DisplayOrder is loaded, but the wealth summary sorts by amount, not by this column.

All direct treasury balance writers and transfers

Section titled “All direct treasury balance writers and transfers”

Besides the income credit and the expense debit, only the following set the treasury directly. Nothing else in the game writes the treasury balance.

What changes the treasury Effect Transaction coverage
Income credit and expense debit Adds or subtracts the given amount Appends a transaction. Classification follows the database flag, not the direction.
Loading a game Restores FCT_Race.WealthPoints No new row and no replay. StartingWealth and AnnualWealth load separately.
Construction-cycle strategic update After the ordinary tax and financial credits, caps the treasury at 2 x newly calculated annual wealth when it is above that The removed excess is not logged. Applies to standard races (FCT_Race.SpecialNPRID 0), including player and ordinary NPR races.
“SM: Edit Wealth” in the Economics window Replaces the selected race’s balance with a number the window accepts No transaction, no check on the amount and no history snapshot.
Granting independence Resets the copied race’s balance to zero before crediting its share The reset is not logged. The transfer has the ledger-list issue described below.

The treasury of a new race record starts at zero. The initial homeworld grant is an income credit of one year’s homeworld wealth production. It is not a direct addition of the starting wealth value. The Spacemaster Economics window operations list the wealth edit.

Independence bookkeeping differs from a normal transfer. The new race starts as a copy of the original race and at first shares the original’s transaction list. The new race’s income is appended to that shared list, the original race’s expense follows, and then the new race receives an empty list of its own. Until the game is reloaded, the original race’s summary sees both rows and the new race’s summary misses its credit. Saving writes the rows of all races together, each with its own race ID, so a successful save and reload reattaches the credit to the new race. The balance snapshot list is not replaced during independence. The parent and the new race share that list in memory, so each race’s later snapshots can interleave.

Race treasury transactions and company receipt rows are independent of optional event messages. The treasury credit and debit write no event. An event tied to a delivery, scrap or conquest is a separate action of that activity. Hiding or keeping events does not create, remove or replay the matching wealth row. Event recipient, time, category and persistence are described in Intelligence mechanics and on the event types page.

Civilian company accounts

Section titled “Civilian company accounts”

Recording a company receipt appends a receipt row and then credits the company’s balance. A row holds the company and ship, the origin and destination populations, the trade good, the amount, the current game time, and the contract, fuel and colonist flags. No race treasury credit happens inside it. It does not reject zero or negative amounts. Without a ship, the recording fails before anything is stored. The game shows error code 2917 (Function #2917) and the balance is unchanged.

Every change to a company’s balance:

What changes the balance Balance effect Recorded company transaction?
Company creation Sets 2,000 for player-owned companies and 4,000 for NPR companies No. It does not debit race wealth.
Company receipt Adds the given amount Yes, an income-style history row.
Company builds a new civilian ship Subtracts the new class cost No expense row and no race treasury debit. A class normally qualifies only when its cost is below the balance. A company with more than 20 ships takes its first design choice, and one with more than 10 ships its second, whatever the cost, so the cost can exceed the balance.
“Fix SL” button in the Naval Organization window Replaces an exactly zero company balance with 3,000, and removes ships so that no class of that company keeps more than 15 No row and no race debit.
Loading a game Restores FCT_ShippingLines.WealthBalance No credit and no replay.

A company balance is 0 before the company is created or loaded. The available dividend is max(0, min((ship cost + balance) / 10, balance - 1,000)), or zero with no ships. It neither debits a company nor credits a race, and nothing in play uses it. A company ship created directly from a design, as at game creation, appears instantly without the balance debit of a normal build. Retiring an old company ship credits no scrap wealth to the company.

Company balances save independently in FCT_ShippingLines. The receipt save keeps the rows whose current game time - TradeTime is below one year, while nothing prunes the rows held in memory. Loading requires a known company, a known origin population and a known destination population before it adds a row. A missing ship leaves the row without a ship, and a missing trade good leaves it without a trade good. Harvester overflow rows have no populations, so they save with population IDs 0 and are discarded on load, although the company balance they credited remains.

The company’s Last Year Income sums every receipt row held in memory with TradeTime after current time - one year, with or without a ship. The receipt history list shows only rows that have a ship. It picks its layout by the colonist flag and the trade good, not by the contract or fuel flags, and it reads the origin and destination population names. A fuel row held in memory has no populations, so it cannot be shown normally. The game shows error code 2907 (Function #2907) and the receipt history list stops at that row, so older rows are not shown. Historical transactions can therefore disappear from the display or on reload while the balance remains.

Treasury persistence and history displays

Section titled “Treasury persistence and history displays”

Saved stores and fields

Section titled “Saved stores and fields”
Table Saved keys and money-related columns Restored as
FCT_Race GameID and RaceID, with WealthPoints, StartingWealth, AnnualWealth and WealthCreationRate Treasury and calculated values load independently. Transactions are not replayed.
DIM_WealthUse WealthUseID, Description, Income, DisplayOrder Category data loads afresh and governs the summary classification.
FCT_WealthData GameID, RaceID, Amount, UseID, TimeUsed Each row reattaches to its recorded race ID and category ID.
FCT_WealthHistory GameID, RaceID, IncrementTime, WealthAmount Balance snapshots. The history display derives changes and period lengths.
FCT_ShippingLines ShippingLineID, GameID and EmpireID, with WealthBalance The company balance loads independently of receipt rows.
FCT_ShippingWealthData GameID, ShippingLineID, ShipID, Contract, Colonist, Fuel, Amount, TradeGood, TradeTime, OriginPop, DestinationPop Requires the company and both populations. A missing ship or trade good can stay empty.

Treasury persistence and retained summaries

Section titled “Treasury persistence and retained summaries”

Saving stores the treasury on its own in FCT_Race.WealthPoints. The transaction save deletes the current game’s FCT_WealthData rows and writes the transactions held in memory as GameID, RaceID, Amount, UseID and TimeUsed. Loading restores balances and transactions separately. It does not sum transactions to calculate the treasury. A transaction whose race is missing is dropped. A transaction of a known race with an unknown category is still loaded, without a category. The wealth summary cannot handle such a row. It shows error code 2176 (Function #2176), and its income and expenditure lists stay empty. Category descriptions and Income flags load afresh from DIM_WealthUse, and the saved rows store only UseID. Changes to the category data can therefore reclassify old transactions without changing the balance.

The treasury save filter keeps a row when TimeUsed - current game time is below one year in seconds (31,536,000). For ordinary past and current transactions this is always true, so it performs no one-year expiry. It rejects only timestamps at least a year in the future. No routine in play removes treasury transactions. Rows are individual appended records, not merged per category or timestamp.

The wealth summary in the Economics window shows race-wide totals, even though it opens for a population. It counts transactions with TimeUsed after current time - selected period, uses the Income flag, sums each category, hides categories whose net amount is zero and sorts by amount, highest first. The boundary is strict, and there is no upper timestamp bound. The annual wealth shown beside these totals is workforce and financial production, not the sum of all income categories.

At the end of the construction-cycle strategic update, every race records a balance snapshot holding the current game time and its current balance. These are snapshots, not transactions. Opening the wealth history display calculates the differences between consecutive balances, then permanently replaces the race’s snapshot list with the newest 18 rows. A later save writes only the list kept in memory. Loading restores time and balance, and the display derives change and period length again.

The daily change divides the period length in seconds by 86400 as a whole-number division, so fractional days are dropped before the division. Periods shorter than a day show dashes, and a 1.5-day interval uses one day as the divisor. After trimming and reopening, the first remaining snapshot is reset to zero change and zero period, losing its difference from the snapshot before it.

Worked examples and balance reconciliation

Section titled “Worked examples and balance reconciliation”

For a known opening balance and transactions recorded with the right direction, closing treasury = opening + income credits - expense debits + unlogged direct adjustments. The category summary instead uses the Income flags and the chosen period. It can fail to reconcile because of the unlogged cap and Spacemaster edits, the wrong classification of ID 52, the shared list after independence, zero or negative entries, timestamp boundaries, missing categories and independently loaded opening balances. It also leaves out civilian company money.

Examples derived from these rules:

  • Opening treasury 1,990, annual wealth 1,000, ordinary cycle credit 20. Logged income is 20, but the treasury ends at 2,000 after the unlogged cap removes 10.
  • Independence of a 25% population share with a treasury of 1,000. The old balance becomes 750 and the new balance 250. Before reload, the original ledger also holds the new race’s ID 8 credit of 250, its own ID 52 expense of 250 shows as income, and the independent race’s ledger is empty. A successful save and reload corrects row ownership but not the ID 52 classification.
  • A player company starts at 2,000, receives 100 and buys a ship costing 500. The balance is 1,600, while the receipt history holds only the 100. The opening 2,000 and the purchase of 500 are absent from the receipt history, and none of that balance is race treasury.

The ledger is not a complete audit trail from which every treasury or company balance can be rebuilt.

Concept map

Section titled “Concept map”

Resources

Section titled “Resources”

Related community documentation and developer posts. These may describe a different game version.