CH710779A2 - Apparatus and method for the automated generation of a reservation set for a transaction of a user in an electronic bookkeeping system. - Google Patents

Abstract

The invention relates to an apparatus and a method for the automated generation of a booking record for a transaction of a user for an electronic bookkeeping. This is in particular characterized in that first transaction details from a transaction document are recorded by machine, which are found for a posting record missing information by machine via a website of the transaction partner, the correct accounting record on the basis of a booking database (41), both accounting records of the user as from other users, and is determined based on a recommendation database (42) with expert-recommended booking details for specific transaction details. For booking the transaction, a booking command is sent with the thus-determined booking record to an electronic accounting means (7).

Description

Technical area

The invention relates to a device, method and computer program for the automated generation of a booking record for a transaction of a user in an electronic bookkeeping.

State of the art

A natural or legal person (hereinafter referred to as user) having a business activity must generally have an accounting. Each transaction is booked with one or more booking records. Each booking record thus contains a set of transaction details (for example, date, amount, description, VAT code) and booking details (account, type of account, etc.) required for the booking. For example, the posting record for an invoice or an invoice element must have a date, an account used for the booking, a type of account (credit / debit), a currency, an entry amount, a VAT code, and a description. Some of these accounting record details are difficult to determine. For example, the account for the booking depends on whether the purchased item is to be posted as an investment or as an expense / expense. This depends on the purchased item as well as the user's activity. Even the VAT code booked is difficult to determine even for professionals. While the bill usually specify the amount of VAT (full, reduced, no), the code must be more accurate. Although there is no VAT on invoices from foreign transaction partners, the VAT code depends on the nature of the product (service or physical product). Generating the correct accounting record for a given transaction is therefore difficult. In the prior art, this accounting is performed internally or by external help (tax advisor, trustee). Mostly the bookkeeping is done with the help of an accounting program, i. done with an electronic bookkeeping.

In an external bookkeeping, external partners (for example, fiduciary or tax accountant office) are instructed to do the accounting for the user. The documents are collected by internal employees and forwarded to the external partner. This books the income and expenditure in a corresponding accounting program and does the accounting according to legal regulations. The decision on how to book a transaction is made here exclusively by the decision of the external partner. In addition, he regularly reports the accounting data to the order organization. However, the user has no direct access to their financial data or has access to it without having knowledge of its completeness. He depends on the transparent data transfer of the external partner. Furthermore, the external partner is not familiar with the user's culture, which can lead to erroneous bookkeeping because he does this according to a standard system and does not respect the specific culture of the user (company).

In an internal accounting employees collect the documents and make the bookings to your best conscience. For this purpose, a corresponding accounting program is also needed. Often, the decision of the correct booking rate of a transaction is decided here exclusively by persons, in this case the employees. This can lead to incorrect posting records or, if several employees carry out posting activities, to different posting records for the same transaction types. In large organizations, automated interfaces with other systems used by the organization, such as the bank or accounting systems, allow parts of the bookings to be automated. However, the last step in the selection of the booking record is still carried out by a natural person. In addition, there are systems that search for similar postings by the user in the same system and propose a posting record from them. This only works if the user has made this booking many times. At the same time, such an error can become independent, because a wrongly booked transaction the first time, is always booked. All of these systems are dependent on people who each have their own opinion and idea of accounting. This leads to different accounting practices and discrepancies. A uniform accounting can therefore not be ensured. In addition, the automatic interfaces are problematic because they only ensure data alignment between two systems. The validity of the information is not checked. In this way, errors can be transferred unnoticed by one system to the other system.

In summary, it is in the electronic accounting of the prior art not yet possible to do a large part of the bookings fully automatic, since the accounting record require a lot of information about the transaction, which are not automatically available and at the same time much experience on the correct posting rate necessary transactions that is not yet automatable. On the other hand, the human being is also a major source of errors because he is responsible for the majority of erroneous and / or inconsistent accounting records and makes the accounting records partly on erroneous assumptions. This can lead to serious consequences for the user. If the organization may have incorrect or no financial information, it may lead to erroneous analysis or wrong decisions that can lead the user to bankruptcy (for example, poor cash planning). Incorrect bookkeeping can also go so far that the statutory provisions can not be complied with, which can result in fines or charges (for example, VAT billing, payroll accounting).

However, further automation of accounting systems has always failed due to the fact that the documents on which a booking must be carried out, e.g. an invoice, does not contain all the information that is necessary for an arrangement of the booking record and even if all the information is available, the experience for the decision of the correct booking are difficult to automate.

Presentation of the invention

It is an object of the invention to provide an apparatus, method and computer program for automatically generating a booking record for a transaction of a user in an electronic bookkeeping system which solves the problems of the prior art. In particular, an automated device, method and computer program is to be created which is independent of the human factor and based on bookings based on objectively determined information.

According to the invention, this object is achieved in a device, a method and a computer program according to the independent claims. The dependent claims relate to advantageous embodiments.

In particular, the combination of categorizing the transactions to determine the category-dependent missing transaction details, automatically completing the missing transaction details by searching the web page of the user's transaction partner, using the experience of other users' bookings stored in a booking database, and using the Bookings stored in a referral database for the various transaction details according to "best practice" allow a majority of the transactions to be posted automatically with the correct booking record.

Another advantage of the device is that it can be self-learning.

Brief description of the figures

The invention will be explained in more detail with reference to the accompanying figures, in which show <Tb> FIG. 1 is a schematic view of an embodiment of a device for automatically generating a booking record for a transaction of a user in an electronic bookkeeping system.

Ways to carry out the invention

In the following, a device for the automated generation of a booking record for a transaction of a user for electronic accounting means and a method for operating such a device will be described. The device is designed to be used by a large number of users, with each user making an independent bookkeeping for himself. The function of the device will be described below with reference to a transaction of a user, hereinafter referred to as "the user". The other users without the user of the device are hereinafter referred to as "the other users".

A transaction is a transfer of at least one value between a user and a transaction partner. Transactions are e.g. the transfer of money for a purchase, rent, lease, usufruct of a property, an object or a right or for the provision of a service or work (wages). In most cases, assets are money, and may also be property rights, other rights, or other tangible or intellectual property that can be linked to value. Transactions belong to different transaction categories, such as sales, purchase, payroll, insurance premium, etc. Different transaction details are necessary and / or helpful for different transaction categories. Thus, for the purchase of a product or service, the identification data of the seller (transaction partner), the purchase object or the purchased service (the transaction subject), the consideration, the Gegenleistungsart (installments, one-time payment), the destination payment address (eg account of the transaction partner), the originating payment address (eg user's account used for the payment), the VAT code, etc. required. Thus, for the sale of a product or service, the identification data of the buyer (transaction partner), the sales object or the sold service (the transaction subject), the consideration, the counter-performance type (installments, one-time payment), the source payment address (eg used for the payment or presumably used account connection of the transaction partner), the destination payment address (s) (eg user account intended for payment), the VAT code, etc. required. The categorization can be arbitrarily coarser or finer. Thus, purchases can be further subcategorized, e.g. according to the type of object and / or the value of the consideration.

A transaction document is an electronic document having first transaction details for at least one transaction of the user. For example, the transaction document could be a bank statement with one or more account transactions. For example, such a bank statement could be automatically transferred from a bank server as an xml file, swift file, text file (e.g., .csv), or as a simple record. For example, the transaction document could be an invoice (debtor or vendor invoice) with one or more transactions. An invoice can also contain multiple transactions. For example, an invoice for communication services from a transaction partner, e.g. A telecommunications company may include mobile services, internet services, landline services, and device purchase and / or equipment rental rates, each of which must be otherwise booked. Another example is an invoice containing different items to be posted under different VAT codes. Such an invoice could be received, for example, as a pdf document, as a photo, as a word document, as an email, etc. in the device. The transaction document could also be a payment receipt or a credit card statement. The electronic document may also have been created by manual user input and received by the manual user interface. The electronic document may also be sent to the device from a database system via an interface, e.g. for invoices created in the database system. Transaction documents usually only contain part of the transaction details required for a booking, i. the first transaction details, so that a booking is usually not possible only on the basis of the first transaction details contained in the transaction document.

The device now comprises an analysis means 1, a data collection means 2, a booking suggestion means 3, a booking database 41, a recommendation database 42 and a man-machine interface 6.

The analysis means 1 is designed to receive and analyze transaction documents, to request possibly necessary transaction details and booking details from the data collection means 2 and to summarize possible values for booking details received by the data collection means and for transaction details of a transaction of the transaction document to possible transaction records to the booking proposal means 3 forward. Preferably, the analysis means 1 comprises a computer interface 11, a document evaluation means 12, a control means 13 and a rule database 14.

The computer interface 11 is adapted to receive a transaction document having first transaction details of at least one transaction between the user and a transaction partner. In the following, only the processing of a transaction of a transaction document will be described here. A second transaction of the same transaction document may be analogous, whereby depending on the transaction category, certain information may be taken over from the first transaction for the second transaction, e.g. the transaction partner. The computer interface is preferably designed to receive transaction documents via a plurality of different interfaces, e.g. one or more of the following interfaces: a connected app on a smartphone (e.g., for photographing invoices), a web page for uploading files, and / or for manually entering information, e.g. via mouse / keyboard / touch screen, a program installed on a local computer for uploading and / or manually entering information, e.g. via mouse / keyboard / touch screen, automatic interfaces for exchanging information, e.g. on request of the receiving system or by receiving a message, etc.

The document evaluation means 12 is adapted to automatically acquire the first transaction details on the basis of the transaction document. In one embodiment, the first transaction details include identification data of the transaction partner, a payment party, and / or another third party involved in the booking. These can be determined both from the content of the transaction document (eg address information in the letterhead or footer, account data of an account movement in a bank statement) and from the electronic source address of the transaction document (eg the IP address, the identification of the interface used,...) , Preferably, the document evaluation means 12 is designed to run an automatic text recognition (OCR) on the transaction document, if the text contained therein is not machine-readable. The text of the transaction document is preferably searched for keywords and patterns. In another embodiment, the document evaluation means 12 is adapted to recognize a code, e.g. a barcode (1D or 2D), a number code, etc., which can be used to query the first transaction details from a database of the user or the transaction partner. In another embodiment, the document evaluation means 12 is adapted to compare the document or individual pages of the document or only parts of a page (eg letterhead or foot or margin) with pre-stored documents (share) to which particular transaction details are stored associated to capture first transaction details. These different collection methods can be applied in combination to one document or applied differently in different combinations depending on the document type.

The document evaluation means 12 is further adapted to detect a transaction category of the transaction on the basis of the acquired first transaction details. In one embodiment, the captured first transaction details are compared to a plurality of transaction details of a non-illustrated database that includes at least one transaction category associated with each stored transaction detail. This database can e.g. the rule database 14, which will be described later. Alternatively, this can also be a separate database. The categorization could also be based on keywords such as "INVOICE" or "LOHNABRECHNUNG", etc., which also falls under the first transaction details.

The document evaluation means 12 is further adapted to detect whether the transaction document contains a plurality of transactions and, if so, to divide the information of the transaction document into a plurality of potential transactions with the associated first transaction details. Two or more transactions recorded as potentially different may be recombined into one transaction at each stage, preferably when a same accounting rate is selected, preferably when they can be summarized in the same accounting record, i. if both can be booked in a posting record with the same posting details.

The control means 13 is adapted to define the missing for a transaction transaction of this transaction category second transaction details and the necessary booking details on the basis of the detected transaction category. The definition here is to be distinguished from the finding in the next step in the data collection means 2. The definition of the missing second transaction details only determines what kind or type of transaction details are still necessary to make a good booking. The concrete realization or the concrete value of the types / types of the missing transaction details is only determined in the next step in the data collection means 2. The second transaction details thus defined are sent as a request to the data collection means 2, which returns the transaction details and possible postings to the control means 13. Preferably, requests for a transaction detail or for a booking detail are made iteratively to the data collection means 2, so that the request and possibly also the definition of the next booking or transaction details already takes into account the value returned by the data collection means 2 for the requested booking or transaction detail can be.

In one embodiment, the control means 13 uses the rule database 14 to define the necessary second transaction details and the booking details. The rule database 14 stores for a variety of transaction categories a set of transaction details and transaction details, which are important for the booking. The control means 13 can now compare the detected first transaction details with the transaction details of the detected transaction category stored in the rule database 14 and thus determine the missing second transaction details. Missing second transaction details often affect the transaction subject, as this is often described with a code or an abbreviation. But it can also be information such as the financial situation of the transaction partner, further information about the transaction partner such as website, payment information, etc. Missing booking details often affect the VAT code and / or the account to be booked. Preferably, the control means generates a request with a number of subqueries, each sub request being the category of the missing second transaction detail (transaction subject) and possibly an indication of the second transaction detail from the first transaction detail (code for product and transaction partner). Alternatively, however, the control means 13 can also make a separate request for every second transaction detail. This could allow to formulate the next request more precisely based on the feedback from the first request, i. define the nature of the missing second transaction detail more accurately.

The booking database 41 is adapted to store the transactions made by the user and other users of transactions of the users with their transaction partners or the nature of the transaction partners. The use of other users' booking records enormously increases the number of existing bookings and allows statistically meaningful statements about the probability of a correct or most common booking for a specific transaction category. This also allows to examine how users with similar activity, i. Users of the same category, book a specific transaction category. The booking database 41 may have for each booking either all the details, i. store the transaction document, the first and / or second transaction details, and the posting details of the transaction record. Alternatively, the booking database 41 may include a selection of the important details and / or an abstraction of the transaction details in transaction categories. Since the users do not have direct access to the booking database 41, but only via the data collection means 2, there is no problem here with regard to data security.

The recommendation database 42 is adapted to store values recommended by experts for particular booking details for various transaction details. The recommendation database 42 is constantly adapted, e.g. with changes in the law. Also, the recommendation database 42 learns automatically by posting commands or booking changes entered via the man-machine interface.

The recommendation database 42 and the booking database 41 are stored centrally for all users and are preferably accessible via the Internet, preferably only via the data collection means 2. Thus, the databases 41 and 42 can always be kept up-to-date centrally for all users.

The data collection means 2 is designed to find the missing second transaction details defined by the control means 13 and the defined booking details. The data collection means 2 preferably has a first data collection means 21 and a second data collection means 22.

The first data collection means 21 is adapted to find the missing second transaction details defined by the control means via the Internet. In this case, use can be made of a website 51 and / or an automatic interface 51 of the transaction partner, the payment service provider and / or the other party involved in the booking. These web pages 51 may be determined, for example, based on the identification data of the transaction partner, the payment service provider, and / or the other party involved in the booking, which may be determined based on the first transaction details. The web pages and / or automatic interfaces of the transaction partners are particularly useful for determining the transaction subject. However, other helpful information such as payment details, legal form of the transaction partner, etc. can be found on it. The websites and automatic interfaces 51 of a financial service provider are particularly helpful for the information about payment information. Web pages and / or automatic interfaces 51 may also be consulted with up-to-date legal information, in particular laws, ordinances and guidelines. These are particularly helpful for the exact determination of the VAT code according to the current legal situation. This could also be used for current social security contributions and / or wages taxes. The addresses for these web pages may be permanently stored for specific transaction and / or booking details to be retrieved upon request by the control means 13 for these transaction details and / or booking details. In one embodiment, the first data collection means 21 has some or all of the second transaction details requested by the control means, i. stored for the type of the corresponding requested second transaction detail, at least one pattern, at least one keyword and / or other features for detecting the corresponding requested second transaction detail. These patterns, keywords or other features may be searched on the website of the transaction partner, the payment service provider and / or the other party involved in the booking to identify the second transaction detail. In another embodiment, the indicia already known from the first transaction details for the second transaction details are searched on the website of the transaction partner, the payment service provider and / or the other party involved in the booking. For example, as previously described, this could be the product code on an invoice stored on the website of the transaction partner, e.g. its webshop, its. The product code is usually uniquely associated with a product at the transaction partner, so that should be sufficient to locate the product on the transactional partner's website. Afterwards, the transaction subject can be recognized by speech recognition and comparison with a product database. This is just an example. In other bills, the product could already be clearly described by the bill itself, but other details might be necessary for a correct posting, e.g. In another embodiment, the first data collection means 21 may also search the posting database as to whether the indicia present on the requested second transaction detail are in other postings in the posting database 41. By means of the first data collection means 22, the missing second transaction details defined by the control means 13 can be completed. Alternatively, fixed web pages for specific transaction detail types could also be requested, e.g. bezügl. the value added tax rate required by law for the transaction subject or the current social security and taxation related to a payroll.

The second data collection means 22 is adapted to find a plurality of possible values for transaction details defined / requested by the control means 13. This may be done on the basis of the values for the requested ones associated with the first and / or second transaction details in the booking database 41

Booking details happen. In this case, the second data collection means 22 and / or even the control means 13 may make a selection of the first and / or second transaction details used for identifying the correct value of the defined booking detail in the booking database 41. The second data collection means 22 in the booking database 41 queries the transactions made for the same category. The category can be divided finer or coarser. This can also be realized dynamically depending on the number of different values for a booking detail and on the number of transactions of the selected fineness of the category stored to a value of the booking detail. For example, in the example of an invoice for telecommunication services with an amount for the Internet services XYZ, it is possible to search roughly for the reservation of Internet services XYZ. If there are many transactions and / or many different values for a booking detail, the category can be further restricted. A restriction of the category can for example be done directly by the specific product XYZ and / or by the nature of the user. In one embodiment, the category may be iteratively adjusted until certain criteria are met.

It is also possible to capture and combine the different values into a booking detail with the corresponding number of transactions in different categories. From this, a confidence value can be calculated for each value for a booking detail per category, the higher the more transactions per value, the less alternative values in the category and / or the finer the category. The trustworthiness of a value of a booking detail in a category is thus based on the fineness of the category, the number of transactions for that booking value of that category, and the number of alternative booking values (and possibly their frequency). At the same time, the trustworthiness of a booking may depend on the source of the data, so that the booking details of the accounting records of trustees / tax advisors are weighted higher than those booked by an amateur. The booking records automatically posted by the system could be placed therebetween. The trustworthy could also depend on the occupational group, so that a booking record is rated by a user of the same type of profession more familiar than from other occupational categories. The confidence values of a value of a booking detail could thus be averaged over various parameters, such as subtleties of the categories, origin and / or occupational category with the corresponding confidence values. However, such trustworthiness could also only be calculated in the control means 13 or the booking proposal means 3 when the necessary data is transmitted to them. The number of booking detail values, the frequency of booking detail values, or other values directly proportional to the number of booking detail values are used as equivalent in this invention.

The second data collection means 22 is further adapted to find one or more possible values of a requested booking detail for the transaction based on the booking details associated with the first and / or second transaction details in the recommendation database 42. In this case, the second data collection means 22 and / or even the control means 13 can make a selection of the first and / or second transaction details used for identifying the correct value of a booking detail in the recommendation database 42. The same or different transaction details as in the booking database 41 can be used. Also, similar to the booking database 41 for the recommendation database 42, the values of the defined booking details for different rough categories could be controlled and provided with a trusted value depending on the number of possible booking types and the fineness of the category.

It has previously been described that the values for each booking detail in the booking and / or recommendation database 41, 42 are queried individually. If several accounting details are defined and requested together in the control means 13, the database query in each of the databases can also immediately query the sets of values for the defined set of booking details. On the one hand, this can help to increase the accuracy, but it can cause the number of records found to decrease.

The data collecting means 2 sends the possible values of the at least one requested booking detail, with the trusted values, frequencies and / or other data that can give a statement about the trust of the value of the booking detail back to the control means 13. In one embodiment the data collecting means 2 also the requested second transaction details back to the control means 13. In the following, the advantage will be described to take the "detour" via the control means 13.

First, based on the feedback from the data collection means 2, the control means 13 can detect whether the data situation is sufficient to make an informed booking decision in the accounting proposal means 3. For example, a particular product might return a variety of values for a booking detail that differ in further product details. For example, the product could be a car. For cars but there are depending on the price, or type (trucks, passenger cars) other types of copying. Therefore, upon a request of the product category Auto to the data collection means, a plurality of equivalent values for a booking detail, e.g. different accounts with the same trustworthiness. Based on the number of (equivalent) booking types or other criteria, the control means 13 could define third transaction details that might help to further restrict the number of booking detail values and send a re-request to the data collection means 2. The decision as to whether a new request is sent to the data collection means 2 could also be made on the basis of the rule database 14.

Second, the control means 13 may use the feedback data to improve the rule database 14 so that the next time a user has a same or similar transaction, the transaction category may be better (finer) ranked and / or assigned the transaction category necessary second transaction details can be adjusted.

Third, the control means 13 may define a plurality of possible accounting records based on the second transaction details received from the data collection means 2, on the basis of the values of the defined accounting details received by the data collection means 2, and / or on the basis of the first transaction details. This can also be done on the basis of the rule database 14.

The accounting proposal means 3 is adapted to determine a correctness value for each of the plurality of accounting records received by the control means 13. The correctness value is determined, for example, on the basis of the frequencies and quality (correctness value) of the values of the booking details correspondingly used in each accounting record from the accounting database 41 and the values of the accounting detail (s) found in the recommendation database 42. The correctness value of each accounting record can be determined, for example, on the basis of the confidence values of the second transaction details and values of the defined accounting details used in the corresponding accounting record, determined in the data collection means 2. If the confidence value in the data collection means 2 was not calculated or not passed on, it could be calculated in a similar manner.

The booking suggestion means 3 is further adapted to select a booking record on the basis of the correctness values. This is preferably done by selecting the posting type with the largest correctness value. Preferably, it is also checked whether the selected booking type meets a specific quality criterion. This could be done, for example, by comparing the correctness value to a threshold and / or by checking whether there is a sufficient difference to a next smaller correctness value of the next ranking entry. If this is not the case, a renewed request for better data can be sent to the control means 13.

Alternatively, a request to the man-machine interface 6 are sent. Preferably, this man-machine interface 6 is accessible by experts who decide on the basis of the transaction document the correct booking type. Preferably, through the man-machine interface 6, the experts can directly adapt the recommendation database 42 in order for the recommendation database to make a correct recommendation for such a transaction. Preferably, different experts have different expert user identifications. Different expert user identifications can be associated with different areas of expertise, so that depending on the problem, other experts can be requested. Preferably, the request is simultaneously sent to a plurality of expert user identifiers, and the majority of responses are combined into one answer. This can minimize the risk of a wrong answer.

The booking suggestion means 3 is further adapted to store the selected booking record with at least a part of the first and / or second transaction details and / or with the transaction document and / or with the booking details in the booking database 41.

The accounting proposal means 3 is further adapted to send a booking command to the electronic accounting means 7 for booking the transaction with the selected accounting record.

Preferably, the booking suggestion means 3 is further configured, before determining the correctness values, the selection, storage and transfer of the accounting record to analyze the accounting records received by the control means 13 and possibly with these sent additional information whether they meet certain quality criteria. If this is not the case, a renewed request for better data can be sent to the control means 13. Alternatively, a request can also be sent to the man-machine interface 6.

The device may, but need not, be combined in one device. The means of the device may be used in various devices, e.g. Computers realized by network means, e.g. LAN or Internet, are interconnected.

Claims (19)

1. A device for the automated generation of a booking record for a transaction of a user for electronic accounting means (7) comprising: a booking database (41) with a plurality of booking records, each booking record containing at least one booking detail field with one transaction detail of a transacted transaction and at least one transaction detail field with each transaction detail of the transacted transaction, the plurality of transaction records pertaining to transactions of the user and other users ; a recommendation database (42) having a plurality of recommendation records, each recommendation record including at least one transaction detail field with transaction details and a booking detail field with a booking type recommended by experts for the corresponding transaction details of the at least one transaction detail field; A computer interface (11) for receiving an electronic transaction document having first transaction details of a transaction between the user and a transaction partner; Document evaluation means (12) for automatically acquiring the first transaction details from the transaction document and detecting a transaction category of the transaction based on the captured first transaction details, the first transaction details comprising identification data of the transaction partner; Control means (13) for defining the second transaction details missing for a booking of the transaction of this transaction category and the booking details necessary for the booking of the transaction of this transaction category on the basis of the detected transaction category; and for generating a plurality of possible booking records for the transaction based on the first transaction details, the second transaction details received from a data collection means (2), and the booking details received from the data collection means (2); Data collecting means (2) formed for automatically locating the missing second transaction details via the Internet on a web page and / or via an automatic interface of the transaction partner, the web page or the automatic interface being determined on the basis of the identification data of the transaction partner and one of the second defined by the control means (13) Transaction details is a transaction subject; for automatically querying a plurality of possible values for each of the transaction details defined in the control means (13) for the transaction on the basis of the booking details associated with the first and / or second transaction details in the booking database (41) and on the basis of the first and / or or second transaction details in the recommendation database (42) associated reservation details, wherein the frequencies of the possible values in the booking database (41) are determined, and Booking proposal means (3) formed for automatically determining an accuracy value for each of the plurality of possible booking rates defined by the control means (13) on the basis of the frequencies of the booking details values used in the accounting records, for the automatic selection of a booking record on the basis of the correctness values; for generating a booking record in the booking database (41) with the booking details of the selected booking record in the at least one booking detail field and at least a portion of the transaction details of the selected booking record, the first transaction details, and / or second transaction details in the at least one transaction detail field; and for sending a booking command to the electronic accounting means (7) for posting the transaction with the selected accounting record. 2. Apparatus according to claim 1, wherein the accounting suggestion means (3) is arranged to decide, based on the correctness value of the selected accounting record, whether the selected accounting record is correct, the accounting proposal means (3) being adapted to make a new request to the data collecting means (2 ) if the selected booking record was not decided correctly. 3. Apparatus according to claim 1 or 2, wherein the booking suggestion means (3) is adapted to test the quality of the received possible booking records before selecting the booking type and, if the quality was found to be insufficient, a re-request to the data collecting means ( 2) sends. Apparatus according to claim 2 or 3, wherein the re-request is sent to the data collection means (2) via the control means (13), the control means (13) defining third transaction details and / or further accounting details for the data collection means (2). 5. Device according to one of claims 1 to 4, wherein the control means (13) is adapted to analyze the second transaction details received by the data collection means (2) and possible values of the defined accounting details, and depending on the result, either the possible accounting records to send the posting suggestion means (3) or to define third transaction details and to send a new request for collecting the third transaction details to the data collection means (2). 6. Device according to one of claims 1 to 5 comprising a rule database (14) for storing a plurality of transaction categories, wherein for each transaction category corresponding for a booking of these important transaction details and possibly additional identification features for the transaction category are stored, wherein the document evaluation means (12) is configured to determine the transaction category based on a comparison of the first transaction details with the transaction details of the plurality of transaction categories. 7. Device according to one of claims 1 to 6 comprising a rule database (14) for storing a plurality of transaction categories, wherein for each transaction category relevant for a booking important transaction details and booking details are stored, wherein the control means (13) are formed, the missing second Define transaction details by comparing the transaction details stored to the detected transaction category with the determined first transaction details. 8. Device according to one of claims 5 to 7, wherein the control means (13) are formed, the rule database (14) on the basis of the reservation proposal means (3) received selected accounting records and / or on the basis of the data collection means (2 ) received second transaction details and / or possible values of the defined booking details. Apparatus according to any one of claims 1 to 8, wherein the accounting suggestion means (3) is arranged to decide, based on the correctness value of the selected accounting record, whether the selected accounting record is correct, the accounting proposal means (3) being arranged to request the credit proper booking to a man-machine interface to send, if the selected accounting record was not decided correctly, wherein the accounting proposal means (3) is formed a booking command with the received from the man-machine interface (5) correct accounting record to the electronic To send the accounting database (41) and the referral database (42) with the correct accounting record received from the man-machine interface (5). 10. The apparatus of claim 1, wherein the document evaluating means is configured to obtain the first transaction detail by pattern recognition comparison of the received document with a plurality of stored documents associated with associated transaction details, by OCR text recognition, by keyword search and / or by Reading a code can be determined. 11. Device according to one of claims 1 to 10, wherein the data collecting means (2) is adapted to find the control unit (13) defined missing second transaction details by keyword search on the website of the transaction partner. 12. Device according to one of claims 1 to 10, wherein the data collecting means (2) is formed by the control unit (13) defined missing second transaction details and / or defined booking details by keyword search on the website of a financial service provider and / or on the website with To find legal texts. 13. Device according to one of claims 1 to 12, wherein the data collecting means (2) is adapted to classify the first and / or second transaction details in categories and to query the values for the defined booking details for these categories from the booking database (41). 14. The apparatus of claim 13, wherein the category of the transaction subject is determined, wherein one of the first and / or second transaction details is the transaction partner, wherein on the basis of the transaction partner the category of the transaction partner is determined and wherein the values of the defined booking details for the categories of the transaction subject and the transaction partner from the posting database (41). 15. The apparatus of claim 14, wherein the category of the transaction subject is determined, wherein the category of the user's activity is stored, and wherein the values of the defined transaction details for the categories of the transaction subject are stored in the transactions of other users stored in the posting database (41) Category to be determined. The apparatus of any one of claims 13 to 15, wherein the category of the transaction subject is determined, wherein the category of the user's action is stored, and wherein the transaction details for the transaction subject categories are those stored in the recommendation database (41) Transactions of other users of the activity of the same category. 17. A method for the automated recognition of a booking type for a transaction of an user for electronic accounting means (7) comprising the following steps: Receiving a transaction document having first transaction details of a transaction between the user and a transaction partner in a computer interface (11); automatically capturing the first transaction details from the transaction document and detecting a transaction category of the transaction based on the captured first transaction details in a document evaluation means (12), the first transaction details comprising identification data of the transaction partner; machine defining the second transaction details missing for posting the transaction of this transaction category and the booking details required for the booking based on the detected transaction category in a control means (13); automatically locating the missing second transaction details via the Internet on a web page and / or via an automatic interface of the transaction partner in a data collection means (2), the web page or the automatic interface being determined on the basis of the identification data of the transaction partner and one of the control means (13) defined second transaction details a transaction subject is machine querying a plurality of possible values for at least one defined transaction detail for the transaction based on the booking details associated with the first and / or second transaction details in a booking database (41) and based on the first one and / or second transaction details in a recommendation database (42) associated reservation details in the data collection means (2), wherein the frequencies of the possible values of the at least one defined reservation details determined in the booking database (41) w wherein the posting database (41) comprises a plurality of booking records, each booking record comprising at least one booking detail field with one transaction detail of a transaction made and at least one transaction detail field with each transaction detail of the transaction being executed, the plurality of transaction records relating to transactions of the user and another user, wherein the recommendation database (42) comprises a plurality of recommendation records, each recommendation record including at least one transaction detail field with transaction details and a booking detail field with a booking type recommended by experts for the corresponding transaction details of the at least one transaction detail field; mechanically generating a plurality of possible accounting records for the transaction based on the first transaction details, the second transaction details received from a data collection means (2), and the accounting details received from the data collection means (2) by the control means (13); determining a correctness value for each of the generated accounting records based on the frequencies of the values of the defined accounting details used in the accounting records in the accounting database (41) in an accounting proposal means (3); selecting a booking record on the basis of the correctness values in the accounting proposal means (3); Generating a booking record in the booking database (41) with the booking details of the selected booking record in the at least one booking detail field and with at least a portion of the transaction details of the selected booking record, the first transaction details, and / or second transaction details in the at least one transaction detail field; Sending a booking command to the electronic accounting means (7) for posting the transaction after the booking suggestion means (3) with the selected accounting record. 18. Computer program formed when executed on a processor to carry out the steps of the method according to claim 17. 19. A computer program product configured to execute the steps of the method of claim 17 when executed on a processor.