Chart of Accounts
What It Is
A chart of accounts organizes the destinations used to record one business unit’s money. Its GL accounts identify cash, liabilities, income, expenses and other accounting categories with codes familiar to the finance team. Each account belongs to the unit and has its own currency and type. A descriptive name helps staff recognize it, while the stable code supports later references and accounting exports.
The concept also includes the configuration that directs financial work into those accounts. Standard posting purposes can select default accounts. Bank and merchant accounts point to the chart so deposits and processor receipts have destinations. Departments and projects supply reporting dimensions beneath the unit. Together these facets explain where the money is recorded and how it can be grouped without requiring a separate conceptual explanation for every configuration table.
What It Is Not
The chart describes available destinations; it does not contain the posted ledger entries themselves. Batch posting owns those entries and resolves the destinations it needs. A payment method describes how money arrives, while a receiving account describes its financial destination. A department or project classifies activity within a set of books and does not create a separate accounting entity.
How It Is Used
An accountant selects a unit and enters the accounts used by the organization’s financial system. The controller reviews default purposes from the chart page, then configures bank and merchant destinations and any reporting dimensions. Other staff mostly encounter these records through selectors. Descriptive corrections are possible, but stable identities and dependency refusals prevent an account from disappearing underneath configuration or financial history that still needs it.
Missing setup can be addressed before posting without stopping staff from issuing invoices. The chart page’s notice provides an early prompt for important defaults. It is still the posting workflow that must resolve the account required for a particular document.
Its Facets
GL accounts. Codes and types distinguish the available financial destinations. Names supply readable labels without replacing account identity.
Standard purposes. Default assignments provide unit-level fallback choices. Expected types communicate a purpose’s usual treatment, although the service and console currently apply those expectations differently.
Bank destinations. A bank record links a recognizable deposit account to the chart. Its descriptive number information is limited to the last four digits.
Merchant destinations. A merchant record identifies processor-related receipts and their clearing account. Processor selection and connection are distinct; the configuration’s status does not establish live processing.
Reporting dimensions. Departments and accounting projects give product accounting a way to classify financial activity more finely. Their current labels follow name corrections while their codes remain stable.
Tax liabilities. Rate-to-account mapping directs collected tax to a unit’s payable destination. The mapping has a financial purpose even as tax determination moves to Commerce.
How It Relates
The business unit supplies the owning context. Product accounting selects destinations and dimensions from the chart, and posting uses explicit choices and defaults when it processes financial documents. Reconciliation owns settlement behaviour associated with merchant records. Tax setup currently carries payable mappings alongside its rates, leaving a boundary to resolve during the ownership transfer.
What It Could Become
The product should publish required default purposes in a shared service contract so different clients can explain missing setup consistently. It should also settle whether account-type guidance is advisory or restrictive in every client. A separate payable-mapping record could preserve Accounting’s financial responsibility while Commerce owns the tax configuration.