Version en español
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.