> ## Documentation Index > Fetch the complete documentation index at: https://docs.garmentflow.ai/llms.txt > Use this file to discover all available pages before exploring further. # The finance ledger > The single record behind every finance figure in GarmentFlow — what it captures, why every entry is permanent, and how corrections are made by reversing entries instead of edits. Every figure on a finance screen in GarmentFlow — the receivables aging, the payables worklist, a customer statement, the balance owed to a vendor, the realized gain on a foreign-currency payment — reads from a single record: the **finance ledger**. The ledger is the workspace's permanent log of every money movement that affects what customers owe, what you owe vendors, and the gain or loss the workspace realizes when a foreign-currency payment settles at a different rate from the one the invoice was booked at. This page explains what the ledger captures, why every entry on it is permanent, and how corrections are made without ever editing or deleting an entry. It is the canonical page for the model; the [Finance module](/modules/finance) and the object pages for invoices, receipts, payments, and the debit and credit notes all describe their own behavior and link back here for the ledger rules. ## The mental model The ledger has **three sides**, and on each side it records a running list of **entries**. Each entry is a single money movement — a charge raised, a receipt taken in, a payment made out, a deposit applied, a correction, or a realized foreign-exchange gain or loss. The balance on a side is the running net of its entries. The three sides: * **Receivables** — what customers owe the workspace. Charges raised against a customer add to the balance; receipts and applied deposits reduce it. * **Payables** — what the workspace owes vendors. Vendor invoices add to the balance; payments out and applied prepayments reduce it. * **Foreign-exchange gain or loss** — the realized gain or loss that arises when the rate on the day a foreign-currency invoice is paid differs from the rate that was in effect when the invoice was booked. This side is a profit-and-loss view, not a counterparty balance, and is recorded in the workspace's reporting currency. Three things follow from the model and carry the rest of the page: * **The balance on a side is always the net of its entries.** There is no separate figure kept somewhere that could fall out of step with the entries that produced it. * **An entry is permanent once it is recorded.** It is never edited and never deleted. * **Corrections are made by recording a new entry that reverses the one being corrected.** Both stay on the ledger; the reversal carries a link back to the entry it cancels, so the audit trail reads in full. The rest of this page expands each of these. ## What an entry records Every entry on the ledger carries the same facts, regardless of which side it sits on: * **The side** — receivables, payables, or foreign-exchange. * **The kind of movement** — see the next section. * **A direction** — debit or credit, in the accounting sense; the balance on the side adds or subtracts the entry's amount according to its direction. * **The amount in the document's own currency**, and the equivalent in the workspace's reporting currency at the rate in effect on the entry's date — so a balance can be read either in the original currency or rolled up into the reporting currency. * **Who and what it relates to** — the customer or vendor, the order, the invoice or vendor invoice, the receipt or payment, the shipment, and the manufacturing order, where each applies. * **The date the movement happened** — the issue date of an invoice, the payment date of a receipt, the day a correction is recorded — kept separately from the moment the entry was written so reporting can be cut by the business date. * **Who recorded it.** * **Notes and any external reference number** the entry carries. The amounts on an entry are always positive — whether the entry raises the balance or lowers it is carried by the entry's direction, not by a negative amount. ## The kinds of entries The ledger recognises six kinds of movement. Each one is created by a specific action on a Finance surface; you do not write entries onto the ledger by hand. * **Charge raised.** A customer invoice (a charge to receive) or a vendor invoice (a charge to pay) recorded against its counterparty. On a customer statement of account this entry appears under the **Charge** column, and the period's total appears as **Total Charges**. This is what opens a new balance. * **Receipt.** Money received from a customer and applied to one or more open customer invoices. Recorded on the receivables side. * **Payment.** Money paid out to a vendor and applied to one or more open vendor invoices. Recorded on the payables side. Vendor payments only post to the ledger when they are [approved](/admin/user-management#maker-checker-approvals) — a payment in draft or awaiting approval does not move the vendor's balance. * **Deposit applied.** A customer advance receipt being applied against a customer invoice raised later, or a vendor prepayment being applied against a vendor invoice received later. The application reduces the balance on the side it sits on. * **Adjustment.** A manual correction, an opening movement, or any other recorded change that does not arise from an invoice, receipt, payment, or deposit application. Used sparingly; the action is always attributed to the user who recorded it. * **[Realized foreign-exchange gain or loss](/reference/glossary#realized-foreign-exchange-gain-or-loss).** When a foreign-currency invoice is paid at a rate that differs from the rate it was booked at, the gain or loss is recorded as its own entry on the foreign-exchange side, in the workspace's reporting currency. The original receivables or payables invoice and payment each post in their own currency on their own side; the realized gain or loss is the third entry that captures the rate movement. See [Foreign exchange](/modules/foreign-exchange) for the full behaviour, including the re-stamp that runs when an order's currency is changed. A single business action can produce more than one entry. Recording a customer receipt against an open foreign-currency invoice, for example, posts the receipt itself on the receivables side and — when the rate has moved since the invoice was booked — a realized gain or loss on the foreign-exchange side. The two entries commit together: either both land or neither does. ## How balances are read A balance is always the running net of the entries that make it up. Reading a balance off the ledger is the same operation on every side: * **A customer's outstanding balance** — sum of the charges raised against the customer, less the receipts and deposits applied to them. * **A vendor's outstanding balance** — sum of the vendor's invoices, less the approved payments and the prepayments applied to them. * **The workspace's realized foreign-exchange result** — sum of the gains less the losses recorded on the foreign-exchange side. Because the balance is read off the entries on demand, it cannot fall out of step with them — there is no stored figure to disagree with the entries that produced it. Balances are kept per counterparty and per currency. A customer invoiced in USD and again in EUR carries two outstanding figures, not a blended one; foreign-exchange differences live on their own side and are not folded into either counterparty's balance. ## How corrections are made An entry, once recorded, is permanent. You do not edit it, and you do not delete it. A correction is a new entry that reverses the entry being corrected. The reversal has the opposite direction of the original, the same amount, and a link back to the entry it cancels. Both entries stay on the ledger; the balance after the reversal is the same as if the original entry had never been recorded, but the history of what was recorded and when, and what was later reversed and why, reads in full. This is the only way a balance on the ledger changes once the original entry is in. Several Finance actions use the rule directly: * **Removing an applied deposit.** The deposit application is reversed; the invoice it had been applied against is again open by the amount of the deposit. * **Voiding and reissuing an invoice or a debit or credit note.** The original document's effect on the ledger is reversed; the reissued document posts as its own new entry. See [Invoices](/modules/invoices#voiding-and-reissuing-an-invoice) and [Debit and credit notes](/modules/debit-credit-notes#voiding-and-reissuing-a-debit-or-credit-note) for the document-level mechanic. * **Correcting a manual adjustment.** A reversing adjustment is recorded; the original is kept. The same rule applies to entries the workspace's everyday actions write — charges raised, receipts, vendor payments, and realized foreign-exchange gains and losses. When the action that produced the entry is later unwound, the system records the reversal; it never reaches in to change what was recorded the first time. ## Why every entry is permanent The ledger is the only record finance can rely on. If a single entry could be changed after the fact, the balance read off the ledger would no longer tell a complete story — a figure that disagrees with the team's recollection could not be settled by reading the trail. Keeping every entry, and recording corrections as their own entries, makes three things true that matter in day-to-day finance work: * **Every balance is reconcilable.** A customer's outstanding figure rolls up cleanly from the invoices, receipts, and applications recorded against the customer. A vendor's outstanding figure rolls up cleanly from the vendor's invoices and the approved payments and prepayments applied to them. * **Every change has an author and a date.** Each entry — including each reversal — carries who recorded it and when. The audit log on the workspace reads the same history under its business-object view; see [Audit log](/admin/audit-log). * **No action erases a number that was once on the ledger.** A void, a reversal, or an undo is itself an entry, visible on the ledger and on the reports that read it. ## Where you encounter the ledger You do not open the ledger as its own screen — it sits behind the [Finance module](/modules/finance) and surfaces in everything that reads it: * **Receivables and Payables tabs** read the per-counterparty balances and the aging that depends on them. * **The Receipts and Offset / Notes tabs** record their entries directly onto the ledger. * **The Approvals tab** governs which vendor payments and debit and credit notes are eligible to post; an unapproved document never reaches the ledger. * **The Reports tab** — the receivables and payables detail reports, the statements of account, the advance-receipt ledger, and the voucher export — reads from the entries on the ledger. The order's Payment Summary card on the [Orders module](/modules/orders) and the per-vendor figures on production work both resolve their numbers through the same ledger. ## Related concepts * [Finance module](/modules/finance) * [Foreign exchange](/modules/foreign-exchange) * [Maker-checker approvals](/admin/user-management#maker-checker-approvals) * [FX rates](/admin/fx-rates) * [Audit log](/admin/audit-log) * [Order lifecycle](/concepts/order-lifecycle)