## 7 BFS Architecture Components
### Actors, Roles, Elements, and Fundamental Processes
* Variables from GeneralLedgerAccount and its entries are utilised by the validator of the BFS system to facilitate input values within the novel BFS UTXO model and in the BFS system's _funds verification consensus_ mechanism. * **Trial Balance (TB):** A list of the debit and credit entries and footings for each ending account balance from the GL. This is the last repository prior to the publication of the final _financial statement_ reports within the BFS system's filing history. _Financial Statements._ These are the outputs of the accounting process forming a reporting package through a balance sheet, income statement, etc. [9]. They contain anonymised and aggregated data on business transactions over a selected accounting period published in the block of the chronological filing history in the BFS system. In the BFS system, the financial statements are constructed in accordance with the double-entry accounting practices in [9]. The top-level components critical for the construction of the BFS system's financial statements are ReportEntry, Report, enum ReportType, and final FinancialSatements. They are described as follows:  
* ReportEntry is an elemental data structure that represents the final balance entry extracted from the GL. In the BFS system, each instance of ReportEntry for the financial statements contains a map of all cryptographic identifiers of the completed business  
Figure 9: BFS account and its hierarchy. transactions that affected this reporting value. This feature ensures that the origin and authenticity of every financial record can be securely traced back to its source, significantly enhancing the transparency, security, and reliability of published reports. This innovation makes accounting falsification challenging, providing regulators with an additional data authenticity tool within the domain of financial accounting and potentially setting a new standard for auditability and verifiability in the digital age. * Report is an integration of the traditionally defined financial report, such as a \"balance sheet\", within the BFS system. * enum ReportType is an initial categorisation mechanism for generating financial statement reports. This enumerator serves as a final consolidation tool for the hierarchical grouping of accounts. Each element of this enumerator also marks the type of financial report added to the final reporting package. * FinancialSatements is the final packaging for all reports for this accounting period. This object is the one that will be subsequently packaged within the data structure of the block in the filing history blockchain, as illustrated in Step 7 of the accounting cycle in Figure 5.  
_Account to Financial Statements Data Flow_. Figure 10 illustrates the process of data communication across several contexts within the BFS architecture, grouped into \"Journals and Ledgers\", \"Account and its Hierarchy\", \"Financial Reporting\", and \"Blockchain\". This data flow is essential for understanding how the BFS system follows traditional accounting practices. It demonstrates the logical path of data that underpins the generation of a financial statement such as a \"balance sheet\". The data flow model demonstrates how the hierarchical data structure for the consolidation of accounting information is designed within the BFS system and further reinforces how the data path is designed in the BFS system's accounting flow. By incorporating traditional accounting practices within the design and implementation of the BFS system, the COA repository houses accounts that do not contain monetary units. This data flow further showcases how these fundamental financial accounts that do not contain monetary units are processed to derive values from the ending balance of GeneralLedgerAccount in the GL for the corresponding AccountIDs, together with the cryptographic transaction hashes and public keys of counterparties, ensuring the origin and authenticity of every financial account.