## 7 BFS Architecture Components
### Actors, Roles, Elements, and Fundamental Processes
Each account is uniquely identified by an AccountID and its name. These accounts are systematically consolidated by AccountCategory and further grouped under AccountClass, enabling the streamlined compilation of BFS. The internal logic of a hierarchical numbering of accounts contributes to a deeper understanding of the nature and the role of each account within the financial accounting framework [9] which, in turn, is designed to reflect the business activity of an economic entity. * AccountID is a fundamental element in accounting [9]. In the BFS system, each AccountID is structured to allow comprehensive tracing of transactions affecting account balances within a given accounting period. Additionally, these identifiers are integral to the operation of accounting smart contracts, linking business transactions to appropriate accounts for consistent recording in journals and accurate reflection in financial statements. * AccountCategory is an enum designed to enable the standardised and hierarchical consolidation of accounts within a specific AccountCategory. The ordering of AccountCategory can contain elements such as CASH(), OTHER_ASSETS(), and more. This alignment with traditional accounting practices within the BFS system serves as a standardised categorisation structure for the representation of financial information for the purposes of reporting, analysis and decision-making [9]. * AccountClass is an enum that enables the standardised consolidation of accounts within each AccountCategory into key categories and classes [9]. These classes are represented within the BFS system as the enum AccountClass and can contain elements such as assets, liabilities, equity, income, or expenses. _Chart of Accounts (COA)_. Another component illustrated in Figure 9 is an application-local repository for a pre-established, logically organised list of all recognised and authorised accounts used for recording all transactions the business can engage in [9]. Accounts in the COA are assigned a unique AccountID and are hierarchically organised based on that ID within the COA data structure. _Accounting Journals and Ledgers._ These are the BFS system's application-local off-ledger data repositories, where the BFS system systematically records accounting data in chronological order throughout the accounting period [9]. As business transactions are completed, economic data, in real time or on demand, are captured and processed by accounting smart contracts. These data are then recorded in the following:  
* **General Journal (GJ):** A data repository for a day-to-day chronological registration of accounting information on all ongoing allowable transactions [9]. It is the first point of entry for the data from completed business transactions, transformed through accounting transaction smart contracts. * **General Ledger (GL):*
* A data repository within the BFS system for a set of homogeneously defined accounts, classified to contain cryptographically linked chronological details of the relevant side of the accounting entries and provide an ending (aggregated) account balance [9]. Traditionally, only monetary values are posted to the relevant accounts in the GL--GeneralLedgerAccount. However, in the BFS application, the existing traditional data structure is significantly enhanced by integrating innovative blockchain concepts:
* Utilising Corda's \"Transaction Vault\" [12] framework, the BFS system embeds a layer of blockchain traceability within each entry of the GeneralLedgerAccount. Each of these entries additionally contains a list of unique cryptographic hashes from relevant business transactions, together with cryptographic hashes of accounting smart contracts that govern the accounting rules for the value posted within GeneralLedgerAccount. This novel feature ensures that the provenance of each financial record is securely and persistently stored, enhancing the integrity and verifiability of the BFS system's accounting records.