Chart of Accounts in TouteGestion: What It Is, How to Set It Up and What It Controls
A chart of accounts is the organisation's controlled list of financial accounts. It tells TouteGestion where financial activity belongs: cash and bank balances, receivables, payables, income, expenses, assets, liabilities and equity. In TouteGestion this is not just a reporting list. The accounts are referenced by journal lines and by operational accounting records such as supplier-bill expense coding and customer-invoice income coding, so the setup determines how transactions reach the ledger and financial reports.
Why you set up the chart before normal accounting work
When a transaction reaches accounting, TouteGestion needs an account to classify its financial effect. A supplier bill line, for example, references an expense account; a customer invoice line references an income account; journal lines reference accounts directly. If the organisation creates vague or duplicate accounts, the software can still record numbers, but management reports and reconciliations become fragmented. The objective is therefore to create a small, controlled structure that reflects how the organisation wants its financial position and performance reported.
Where the setup happens in the app
A user with the accounting.accounts.manage permission opens Accounting → Chart of accounts. The screen lists the organisation's accounts and provides Add account. Account management is organisation-scoped: the page loads accounts for the current organisation rather than exposing one global chart shared by every TouteGestion customer.
Step 1 — Choose the account code
Enter a unique code such as 1000. TouteGestion trims the value and stores it in uppercase. The application prevents another account in the same controlled structure from being created with the same code and returns 'An account with that code already exists.' Codes are identifiers; TouteGestion deliberately does not force a Ghanaian, French or other country-specific numbering convention.
Step 2 — Give the account a precise name
Enter a name that tells the user what should be posted there, for example Cash on hand, Main EUR Bank, Tuition Fee Income or Office Supplies. The name matters during transaction coding and review. Avoid creating several accounts whose names mean the same thing unless there is a genuine accounting reason to keep the balances separate.
Step 3 — Select the accounting type
TouteGestion currently accepts five account types: Asset, Liability, Equity, Income and Expense. This classification gives the account its broad financial meaning. Cash, bank balances and receivables are normally assets; amounts owed are liabilities; sales or fee revenue is income; operating costs are expenses; and owners' or accumulated interests sit in equity. The application validates that the selected type is one of these supported types.
Step 4 — Use a parent account only when hierarchy helps
The Add account form allows an optional Parent account selected from existing accounts. This lets an organisation group related accounts without encoding every reporting distinction into the account name. Once an account is being used as a parent, TouteGestion will not allow that parent to be deleted while child accounts still reference it.
Step 5 — Set the account currency
The Account currency field defaults to the organisation's functional currency when available. It accepts a three-letter ISO 4217 code such as GHS, EUR or USD. For a foreign bank or physical-cash account, enter the currency actually held in that account. This matters because later cash, bank and multicurrency controls need to know whether the monetary account itself is GHS, EUR, USD or another currency rather than assuming every balance is in the organisation's functional currency.
Step 6 — Classify real bank accounts correctly
Tick 'This is a bank account' when the ledger account represents an actual bank account. The form can then retain the bank name, account number and branch. This classification is operational, not cosmetic: TouteGestion uses financial-account identity in banking and reconciliation workflows, allowing cash movement and statement activity to be tied back to the correct ledger account.
Step 7 — Classify physical cash separately from bank
Tick 'This is a physical-cash account' for money physically held by the organisation, such as a cashier drawer, till float, safe or petty-cash fund. TouteGestion enforces two rules: a physical-cash account must be an Asset, and one account cannot be both bank and physical cash. Existing eligible non-bank Asset accounts can also have their cash classification changed from the accounts table.
What happens when you press Add account
TouteGestion validates the code, name, account type, currency format and bank/cash combination, then creates the account under the current organisation. It writes an audit event (account.create) containing the key classification values and refreshes both Chart of accounts and Cash counts. The new account is therefore not merely text on a setup page; it becomes an accounting object that other workflows can reference.
How the setup affects supplier bills and customer invoices
The accounting data model requires supplier bill lines to reference an expense account and customer invoice lines to reference an income account. That is why account design affects day-to-day coding. If 'Office Supplies' is the intended expense account, coding a supplier bill line to it gives the resulting accounting activity a consistent destination. If 'Tuition Fee Income' is the intended revenue account, invoice coding can feed that revenue classification instead of using an ambiguous generic income bucket.
How the setup affects journals and reports
Manual and system-generated accounting ultimately use account references on journal lines. Those posted lines are what make an account balance meaningful. A trial balance or financial statement can only group and explain activity as well as the underlying account classification allows. Creating 'Electricity Expense' separately from 'Internet Expense', for example, allows those costs to remain distinguishable in ledger analysis; posting both to one generic 'Expenses' account intentionally gives management less detail.
Active, inactive and deletion are different controls
The accounts table lets an authorised user activate or deactivate an account, and TouteGestion audits that change. Deactivation is the appropriate lifecycle concept when an account should remain in historical records but should no longer be treated as current. Deletion is stricter: TouteGestion refuses to delete an account if journal-entry lines still reference it, and also refuses deletion while child accounts use it as their parent. Historical accounting therefore cannot be casually destroyed just because the organisation reorganises its chart.
Worked example — setting up a school's bank and fee income
Assume a school operates in GHS and receives tuition into its main bank account. In Chart of accounts, finance creates 1100 — Main Bank, Type Asset, Currency GHS, marks it as a bank account and records the bank details. It also creates 4100 — Tuition Fee Income, Type Income. When tuition billing and receipt/accounting workflows use those classifications, the organisation can distinguish the amount recognised as tuition income from the cash held in the bank. The bank classification also gives reconciliation workflows a real financial account to work against. The chart has therefore shaped both the accounting entries and how users later understand the balances.
Worked example — why not create a bank account as Expense
If a user tries to model physical cash as an Expense account and mark it as physical cash, TouteGestion rejects the setup because physical cash must be an Asset. This prevents a configuration error from turning money the organisation holds into a cost category. The same principle is why bank/cash classification and account type must be designed together rather than treated as unrelated labels.
A practical setup sequence for a new organisation
Start with the organisation's functional currency and reporting needs. Create the core Asset, Liability, Equity, Income and Expense accounts; add only useful parent groupings; identify actual bank and physical-cash accounts with their currencies; then review the list for duplicate meanings before operational users begin coding bills, invoices and journals. Expand the chart when a real reporting or control need appears rather than creating hundreds of speculative accounts on day one.
Practical configuration checklist
- each account has a unique code and unambiguous name
- account type reflects the financial substance
- parent relationships are used only where useful
- bank accounts are marked as bank and carry the actual account currency
- physical cash is a non-bank Asset account
- foreign monetary accounts use their actual ISO 4217 currency
- obsolete accounts are deactivated rather than deleting referenced history
- income and expense accounts are specific enough for invoice and bill coding
- the resulting structure supports journals, reconciliation and reporting without unnecessary duplicate accounts
Connect accounting structure, workflow and reporting.
Explore the product or continue through the Accounting Knowledge Centre.