With Bookkeeping 2.0, Bookkeeping 1.0 is initially replicated only electronically via a financial accounting software (FinAcc). Nevertheless, there are also clear differences. The core of FinAcc is a file with the current postings, from which accounts and journals are supplied with data. All data is recorded in the file via an input mask, or copied in via interface and data transfer.

As a legal requirement, it must be ensured that the bookings cannot be changed later. Unlike a detection on paper, however, an error correction can be made possible. A booking is considered to have taken place when the journal was printed with this booking. However, they are then only provided with a flag that they must not be changed anymore, and the next journal only prints postings without this flag. There are also other characteristics, e.g. for paid invoices (which corresponds to the figures - see 2.5.1. -) or open items.

The file assigns the postings to periods. This can be controlled by the document date or with a separate input. There are usually 14 periods per year. A period 0 includes the balance carryforward from the previous year. Here only automatic bookings are possible. In periods 1 to 12, the current transactions of the individual months are recorded. A period 13 records the operations that should not be assigned to a particular month. These are in particular corrections and valuations in the context of the annual financial statements. But even with quarterly statements, you could record such postings in period 13. For each financial year, a separate subdirectory with data from 14 periods is maintained. This allows you to switch between the databases of several years. When a period is closed, it can no longer be booked in it. The data is retained and can be evaluated without restriction.

FinAcc clearly differentiates between database and evaluation. While in Bookkeeping 1.0 the data was still recorded in journals and accounts, they are only evaluations in Bookkeeping 2.0. Balance sheet and income statement are independent evaluations in addition to the accounts. There are therefore no final bookings. At a turn of the year, a new subdirectory with the following year is created and empty accounts are first copied into it. Subsequently, the final balance of the balance sheet accounts is entered automatically as the balance carryforward in the period 0 of the new year. The sum of all offsetting postings corresponds to the profit of the previous year. For changes in the old year, the balance contracts are updated.

While in Accounting 1.0 the balance was defined as the settlement amount that offsets debit and credit and that was transferred to the balance sheet or income statement, the balance in Accounting 2.0 is the debit or credit overhang. Assets therefore regularly have a debit balance, even though they were transferred to the balance sheet in the accounting system 1.0 with a credit posting (called the balance). So here are the old terms for about 40 years out of date.

The evaluations of FiBu are today mainly generated as a file and kept electronically. In addition to this archiving, the data can also be made available for various tasks in the company as a data source. For this purpose, it must be asked who needs which information for his tasks. In addition to legal requirements, these requirements determine the scope of the accounting 2.0.

In Bookkeeping 1.0, there was the alternative of keeping a journal for all bookings in strict chronological order, or several different voucher journals for different groups of business transactions, which were then kept chronologically within that journal. Because the journals in Accounting 2.0 are pure evaluations, there are both possibilities side by side.

By printing the booking journal, it is decided that these bookings cannot be corrected. Therefore, mechanical test procedures must be carried out beforehand. Other plausibility checks should also be performed, e.g. whether the cash balances on the accounts match those on the bank accounts or in the cash register. Because the accounting journal reproduces the Journal of Accounting 1.0, it is organized according to the order of data collection. It is therefore more of a documentation and bureaucratic duty than a meaningful evaluation.

In contrast, the document journals are controlled by the document type and the document number. Further limitations are possible. So could e.g. an evaluation with all invoices of a specific number range can be generated on paper or file. For the document journals, the order of data entry is not important. Document journals are more like work aids for specific tasks. But it is also possible that e.g. Monthly complete document journals are created as documentation.

With small extensions it is also possible to generate sorted evaluations according to every other criterion. Alternatively, a data export of all postings could be generated, which can then be read in with a spreadsheet and then sorted. So could e.g. sorting by booking text. Then it would have to be organized that meaningful entries would be made according to which sorting would make sense.

Like the journals, the accounts are not a data store, but an evaluation. Therefore, the printed out on paper accounts have little meaning. On the other hand, it is important to be able to display an account on the screen. If the data were not outsourced, this is also possible for earlier years. This applies to personal accounts as well as general ledger accounts. Because of this constant accessibility, a printed annual account statement is usually sufficient, which can then be produced as a file. Accounts with a large number of postings can also be defined as a summarized account, with which all debit and credit postings in a period are condensed into one number. The details can be read with a screen view.

In the programs, it was planned that the documents were individually entered into a data entry screen via the keyboard and screen. This had the advantage that man could also transfer different processes into a common scheme. This could require a very complex data entry. Over time, however, data transfers from other applications have become increasingly prevalent. The following example describes an interface with which invoices settled 20 years ago could be transferred to accounting. When transferring data from other applications, the records had to be structured similarly. With flexible interfaces, data transfer became much easier.

Pos.1     Pos.2     Length     Type     Designation
    0         6         7     N      Account number
    7         7         1     A      Document type
    8       13         6     A      Document number
  14       19         6     A      Document date
  20       38       19     A      Booking text
  39       39         1     A      Code B = GROSS / N = NET
  40       52       13     N2   Gross amount (Total)
  53       65       13     N2   Net amount (Total)
  66     128       63     N     9 Costs each 7 digits
129     191       63     N     9 Revenue accounts (counter accounts)  7-digit
192     308     117     N2  9 Gross / net.  (if necessary in foreign currency)
309     362       54     N2  9 VAT rates per 6-digit
363     363         1     N     Code currency  (additional foreign currency)
364     370         7     N     Conversion factor (add. Third party)
371     385       15     A     Document number Supplier
386     386         1     A     Blocking / payment note Booking: L = direct debit, E = debit, V = value
387     392         6     N     value date (if pos. 386 = "V"!)
393     393         1     A     Booking mark / side  S = debit, H = credit
394     403       10     A     Search name Person account
404     433       30     A     Postal code / City personal account
434     463       30     A     name personal account
464     493       30     A     Industry Personal account
494     523       30     A     street person account
524     543       20     A     Telephone Person account
544     563       20     A     Fax Person account
564     578       15     A     Account number (bank master)  personal account
579     586         8     N     Bank code (bank account) Person account
587     611       25     A     Bank name (Bank master) Person account
612     636       25     A     Comment Person account
637     652       16     A     VAT ID number Person account
653     667       15     A     Customer number at the supplier (Personal account master)
668     677       10     N     Credit Limit
678     678         1     N     Indicator Reminder 0-9 (see "Dunning") personal account
679     680         2     A     Representative person account
681     683         3     N     Net days personal account
684     686         3     N     Skonto1 days personal account
687     691         5     N2  Skonto1% rate of personal account
692     694         3     N    Skonto2 days personal account
695     699         5     N2  Skonto2% rate of personal account
700     700         1     A     Registration abroad N, E, D    personal account
701     701         1     N     collection item. Pers.kto.  (only with new plant)
702     707         6     A     Document date   (if different from Booking date)
708     709         2     N     Term of Payment ("X" at position 708 effects acquisition of the

                                          payment conditions from the personal account master record
710     748       39     -      Free (always occupy with ASCII 32)

These 44 fields with 748 characters were basically also available for data acquisition on the screen.

Meanwhile, more flexible interfaces are common. Thus, e.g. a particular field is addressed with a code or certain sequences are specified for the fields of the import files, which are separated with TABs. You can also generate your own data from a spreadsheet and read it into the accounting department.