Skip to content

Accounting Support

To support your accounting processes, JustOn

Concepts: JustOn and Bookkeeping

Businesses must do accounting. It mirrors an organization's economic activities - providing a comprehensive and structured recording of all business transactions, expressed in figures. This information is made available to the management and investors, making it the foundation for purposefully controlling the company, and to authorities to comply with legal requirements.

JustOn Billing & Invoice Management continuously produces invoices for the products or services you sell and can, if set up accordingly, register and allocate corresponding payments. In that sense, JustOn also acts as a sales journal or debtors ledger that directly supports your accounting processes. You determine the extend and detail you leverage, depending on your environment and business requirements.

Info

JustOn can act as a subsidiary ledger for invoicing data to support your bookkeeping. The relevant financial statements, like annual reports or income statements, are to be produced by your accounting system.

With respect to the accounting support, JustOn distinguishes four "virtual" integration levels.

Basic

On a basic level, there are the invoices and invoice line items JustOn produces. These records show your sales volume, split into revenue and taxes. If configured accordingly, you can already add required booking account information. By default, the invoice line items hold the G/L account, determined by your rules. Optionally, they can also include the debtor number (populated from the custom Account field ON_DebtorNo) as the contra account.

For your accounting purposes, you can either create reports to just display the corresponding data, or export invoices to CSV files, which are to be fed into your accounting system for further processing.

Advanced

On a more advanced level, you can leverage specifically generated bookkeeping data - booking periods and booking details. They prepare the information obtained from invoices and invoice line items for accounting purposes: Booking details represent records in an accounting ledger, and booking periods represent one month in bookkeeping and aggregate the booking details produced for this month.

By default, JustOn creates one booking detail per invoice line item. It combines multiple invoice line items into one booking detail if specific data match (invoice ID, G/L account, tax rate). For details, see Bookkeeping Data Generation.

The key data involves:

  • booking date
  • account (the G/L account)
  • business partner account (debtor/creditor as the contra account, taken from the debtor number on the account or the business partner account number on the Collective Accounts custom setting)
  • type (Revenue or Tax)
  • amount
Example: Generating default booking details

Consider the following example: One invoice with four invoice line items and the Default recognition rule results in four booking details, split by G/L account and revenue/tax.

Invoice line items

# G/L Account Pos Total Net Pos Total Tax Tax Rate Invoice No.
1 0001 10,00 0,70 7% R12345
2 0001 20,00 1,40 7% R12345
3 0002 30,00 5,70 19% R12345
4 0002 40,00 7,60 19% R12345

Resulting booking details

# Type Account No. Amount Tax Rate Name
1 Revenue 0001 30,00 7% 0001-R12345
2 Revenue 0002 70,00 19% 0002-R12345
3 Tax 2,10 7% 7.0-R12345
4 Tax 13,30 19% 19.0-R12345

booking_details.png
Booking details split by G/L account and revenue/tax with Default recognition rule

The produced booking details are intended either to be exported to CSV files or to be directly transferred to DATEV using the JustOn Connector for DATEV.

Advanced with Revenue Recognition

When creating booking details for invoice data, you can choose to apply revenue recognition rules to control the way the involved data is transformed into booking details. This allows you to handle, if required, deferred revenue (which introduces the new booking detail type Deferred), shortfall amounts or service period amounts.

Example: Booking deferred revenue

Consider the following example: There is an invoice whose amount is to be distributed equally to four booking periods using the Monthly recognition rule.

Field Value
Pos Total Net 1000€
Tax 190€
Grand Total 1190€
Service Period Start 2018-05-01
Service Period End 2018-08-31

Assume the following booking accounts:

  • G/L account: 1111
  • Business partner (debtor) account: 2222
  • Tax account: 5555
  • Deferred revenue account: 9999
  • (Virtual) deferred revenue contra account: 8888

Accordingly, JustOn generates the following booking details:

# Booking Period G/L Account BP Account Type Amount
1 2018-05 5555 2222 Tax 190
2 1111 2222 Revenue 250
3 9999 8888 Deferred 750
4 2018-06 1111 2222 Revenue 250
5 9999 8888 Deferred -250
6 2018-07 1111 2222 Revenue 250
7 9999 8888 Deferred -250
8 2018-08 1111 2222 Revenue 250
9 9999 8888 Deferred -250

Notes:

  • The tax is always booked in the first booking period.
  • 1/4 of the revenue is booked in the first booking period.
  • 3/4 of the revenue is booked to the deferred revenue account in the first booking period.
  • In every subsequent booking period, 1/4 of the revenue is booked and, at the same time, taken out from the deferred revenue account to offset the booked revenue.

Advanced with Payment Data

Your JustOn instance may be set up to capture payment transactions first-hand via figo or the Self-Service Extension. In this case, your business may also require to prepare the payment information for accounting purposes. To this end, you can have JustOn write bookkeeping data for payment balances, again structured in booking periods and booking details.

JustOn creates one booking detail per payment balance change. That is, a change by a delta of 5,00 EUR results in a new booking detail with an amount of 5,00 EUR.

The key data involves:

  • booking date
  • account (debtor/creditor, taken from the debtor number on the account)
  • business partner account (bank account or payment provider as the contra account, taken from a corresponding Collective Accounts custom setting)
  • type (Payment, Prepayment, Refund, Payout or Provider Fee)
  • amount (positive/negative)
Example: Generating booking detail for a payment balance with amount change

Assume the following actions:

  • Register partial payment on invoice
  • Generate bookkeeping data
  • Change amount of partial payment
  • Generate bookkeeping data

The first booking detail creation:

Field Example Value Description
Name 2019-01-15-Foo Inc. Concatenation of payment date and fallback to the account name (no debtor number available).
Amount -35 Taken from the Balance field Amount.
Payment Date 2019-01-15 The date of the payment transaction.
Booking Date 2019-01-15 The booking date may be different from the payment date if the target booking period is closed and the booking detail has been moved.
Payment Hash asd84578 Calculated by JustOn in order to track changes on involved balances.
Type Payment Taken from the Balance field Type.
Balance - Links to the associated balance.
Account No 1111 Set by collective account rules.
Business Partner Account No 2222 Set by collective account rules.

From the second bookkeeping data creation results a booking detail that covers the amount change:

Field Example Value Description
Name 2019-01-15-Foo Inc. Concatenation of payment date and fallback to the account name (no debtor number available).
Amount 5 Calculated as follows: new amount minus original amount (like -30 - (-35) = 5).
Payment Date 2019-01-15 The date of the payment transaction.
Booking Date 2019-02-01 Moved to the next booking period, since the original booking period has been closed.
Payment Hash asd84578 The same hash as for the original booking detail.
Type Payment Taken from the Balance field Type.
Balance - Links to the associated balance.
Account No 1111 Set by collective account rules.
Business Partner Account No 2222 Set by collective account rules.

The produced booking details are intended to be exported to CSV files.

Balances

Invoices, credits, payments, refunds, dunning fees etc. create balance records. Consequently, balances show debits and credits for each account.

Info

Generally, JustOn creates balances automatically with specific operations, for example, finalizing invoices, assigning payment entries, etc. Certain business use cases, however, may require balances to be created manually, like pre-payments or payouts.

Managing Balances
Setting Up Balance Management Options

Balance Concepts

Balances are associated to the account in a master-detail relationship.

JustOn adds up the balance records for invoices and for accounts, thus creating invoice balances and account balances.

  • The account balance is the sum of all balances for a particular account. A positive amount is considered a debit, and a negative amount is considered a credit.
  • The invoice balance is the sum of all balances for a particular invoice. If this sum is 0, the invoice is considered Paid; if the sum is not zero, the invoice is set Open.

The balance aggregation affects the following fields:

Object Affected Field Field Type Description
Account Balance Roll-Up Summary (SUM Balance.Amount) Shows the sum of all balances associated to this account. A positive amount is considered a debit, and a negative amount is considered a credit.
Invoice Balance Currency (16,2) The sum of all balances for this invoice. An invoice is considered paid or settled when the balance is zero.
Status Picklist The main invoice status, is set Open when the balance is not zero, is set Paid when the balance is zero.
Payment Date Date The date on which the payment for this invoice has been received completely. Is cleared when the balance is not zero, is set to the date of the last balance record when the balance is zero.

Think of the following example: A customer has made a pre-payment for an ordered product, and a user registers this, creating a balance record of the type Prepayment. Pre-payments (or any other existing balance records) are considered accordingly upon invoice creation. When the invoice is finalized (its status set Open), JustOn generates a balance record of the type Invoice. The balance record amount equals the grand total amount of the invoice. Then, the user registers the final payment with the invoice, generating a record of the type Payment. The invoice balance records may look like this:

Balance Record Amount Date Description
Prepayment -10 € 2017-03-02 Received a pre-payment of 10 € from the customer
Invoice 25 € 2017-03-27 Set the invoice Open with a grand total of 25 € and a payment due date of 2017-03-27
Payment -15 € 2017-03-31 Received the outstanding 15 € from the customer

The invoice is set Paid (-10 + 25 -15 = 0) with a payment date of 2017-03-31.

Standard Balance Types

Depending on the semantics, there are various types of balances. Some are set by JustOn, others can be selected by users.

System Balance Type Description
Invoice Is created for an invoice on finalization.
Credit Is created for a credit on finalization.
Payment Is created for a registered payment entry.
Clearing Is created for an invoice or credit when it is balanced out (by a corresponding credit or invoice), or for a discount amount when a discounted invoice is paid.
Settlement Is created for an invoice or credit on settlement.
Cash Is created for an invoice with the payment method Cash on finalization.
Dunning Fee Is created for a dunning.

User-selectable balance types include Payment, Refund, Prepayment, Payout and Clearing. Balances are, however, not restricted to these types. You can create new types adding new picklist values to the Type field. In addition, JustOn accepts other type values when importing balances.

Info

In addition, JustOn supports the specific balance type prepaid balance for automatically registering pre-payments.

Automatic Balance Assignment

Usually, JustOn assigns new balances to invoices on finalization if the following conditions are met:

  • The balance does not refer to an invoice
  • The checkbox No Auto Assignment is unselected
  • The amount does not equal zero
  • With respect to the invoice grand total, the amount has a reversed +/- sign

If there is a subscription linked to the balance, the balance is only assigned to invoices of the linked subscription. If there is the field ON_Opportunity__c (Lookup(Opportunity)) on the balance, the balance is only assigned to invoices for the linked opportunity.

You can disable the automatic assignment

  • either selecting the checkbox No Auto Assignment on the balance,
  • or adding and selecting the custom checkbox field ON_NoAutoBalanceAssignment__c on the invoice.

Prepaid Balance

JustOn automatically creates a prepaid balance for pre-payments when an invoice that contains specific pre-payment data is finalized. As opposed to other balances, the prepaid balances are deleted and thus removed from the account when the corresponding invoice is canceled.

This simplifies the import of invoices with pre-payments: there is no more need to import the payment entries in an additional step. In case of an error, you can cancel the invoice and import it again without dealing with duplicate pre-payment balances.

Prepaid balances have particular properties:

  • The balance is automatically created when an invoice with specific pre-payment data is finalized.
  • The balance is automatically deleted when the corresponding invoice is canceled.
  • It is not possible to delete the balance manually.
  • The balance is never split, even on overpayment or when additional payment entries are registered with the invoice.

The checkbox IsPrepaid marks the balance as a prepaid balance. Consequently, deselecting this checkbox removes the particular treatment of prepaid balances.

The checkbox IsPrepaid is not displayed on the balance layout by default.

Setting Up Prepaid Balance Management

Balance Settlement

In the context of an account, JustOn automatically assigns free balances to invoices upon finalization, thus reducing the final payment amount. Free balances are not associated with an invoice and may result from, for example,

  • registered payments for invoices that are canceled,
  • payment entries that could not be matched to an invoice and therefore have been associated with the account,
  • some manual operation.

Info

This functionality is independent from the invoice settlement, which can be set up to offset non-related invoices and credits of an account, as described in Managing Settlements.

Balance Overpayment

You can assign balances to draft invoices that exceed the grand total of the invoice, which results in an overpayment. When the invoice is finalized, that is, set Open, JustOn usually splits the overpayment balance along the open invoice amount: one part covers the open invoice amount and is assigned to the invoice, whereas the remainder is unlinked from the invoice.

Event Balance Record Amount Date Description
Invoice finalization Invoice 100,00 2017-11-20 Invoice balance is created when the invoice is set Open.
Payment entry (75,00) Payment -75,00 2017-11-21 Partial payment is registered.
Payment entry (30,00) Payment -25,00 2017-11-24 Second payment entry of 30,00 is registered and split into two balance records of -25,00 and -5,00.
Payment -5,00 2017-11-24 Remainder balance (-5,00) is unassigned from the invoice. It remains assigned to the account and can be used for a future invoice.

The invoice is set Paid (100 - 75 - 25 = 0) on 2017-11-24.

Info

JustOn assigns any available open balances to invoices on finalization, immediately reducing the open invoice amount. In addition, you can schedule a job in order to have remainder balances automatically assigned to open invoices on a regular basis.

Certain business use cases require overpayments to be kept on invoices. Assume, for example, you receive monthly payments (100,00) for a usage-based service that is invoiced once per year. Now the actual consumption yields a grand total of the yearly invoice that is lower (1150,00) than the sum of the received payments. If you allow an overpayment on the invoice, the difference remains assigned to this invoice, which prevents it to be used for other invoices of this account. You can then refund the overcharged amount (50,00) and manually create an according balance record for the invoice of the type Payout or Refund.

Date Balance Record Amount
2017-01-01 Payment -100,00
... ... ...
2017-12-01 Payment -100,00
2018-01-08 Invoice 1150,00
2018-01-10 Payout 50,00

Enabling Balance Overpayment

Balance Write-off

Some business use cases may require to set the invoice status to Paid and the invoice balance to 0 even if an assigned payment does not exactly match the invoice amount. Differences to cover may, for example, result from currency conversions upon payment matching. You can define the difference that you are ready to accept and offset consequently according to your business requirements. To this end, you specify either a (percentage) threshold or an absolute amount.

Info

You can combine the percentage and the absolute amount. In this case, JustOn limits the calculated threshold to the specified amount.

Assume the following example: There is an invoice (and an according balance record) of 119,00. The customer pays in a different currency, and after converting the payment amount, JustOn registers a payment balance record of -118,00. With a write-off threshold set to 5% (which covers the difference), JustOn automatically creates a write-off balance record of -1, clearing the remaining amount.

Balance Type Amount
Invoice 119,00
Payment -118,00
Write-off -1,00

Enabling Balance Write-Off

Balance Refund

You can refund a payment balance if

  • The payment method for the balance is set to Direct Debit.
  • The balance is unassigned from the invoice.

If supported by your org's payment provider integration, refunding a payment balance directly returns the specified amount to the customer. In JustOn, this operation creates a balance record of the type Refund for the account.

Payment Entries

JustOn allows for tracking collections for invoices. To this end, it can register payment operations that have occurred in external systems as payment entries and match them to invoices. Each payment entry represents a record of a bank statement, that is, a registered payment operation intended to meet an open invoice amount.

Payment entries mark an invoice as Paid or a credit memo as Settled.

You can manually set an invoice Paid using the function Register Payment, which directly creates a balance record. In addition, there are three ways to automatically acquire payment entries:

  • via an integration with an external payment provider, like PayPal or Stripe,
  • importing bank statements from CSV files or
  • retrieving banking transactions from figo.

After importing payment entries, you assign them to invoices. This is a two-step process:

First, JustOn automatically matches payment entries to existing invoices and dunnings. This produces a list of likely matches based on the following main conditions:

  • The invoice has the status Open, or, respectively, the dunning has the status Closed.
  • The invoice number or, respectively, the dunning number is found in the reference field of the payment entry.

If JustOn cannot find a matching invoice number, it compares the contents of the reference field with the account number. For further details, see Matching Logic.

Second, after reviewing the matching proposals, users assign the payment entries to invoices or dunnings. This creates balance records of the type Payment, which are assigned to the corresponding invoices or dunnings. The originally imported payment entries are set to the status Converted.

Overpayments are split along the open invoice amount: one part covers the open invoice amount and is assigned to the invoice, whereas the remainder is assigned to the account. If there are more than one open invoices found for an account, JustOn settles the oldest one first.

For payment entries assigned to dunnings, JustOn distributes the payment amount to the invoices referred to by the dunning. The oldest invoice of the dunning is settled first. In case of an overpayment, JustOn creates an account balance for the remaining amount.

Managing Payment Entries

Payment Amount Calculation

When creating the payment entry from imported payment data, the effective payment amount is calculated as follows:

Field Description
Credit For deposits from customers. An empty value equals 0.
Debit For payouts to customers. An empty value equals 0.
Payment Amount Credit - Debit

Info

The invoice amount or credit amount is matched against the calculated payment amount.

Settling a credit of -10 €

Import

Credit Debit Payment Amount
10 -10

or

Credit Debit Payment Amount
-10 -10
Settling an invoice of 10 €

Import

Credit Debit Payment Amount
10 10

or

Credit Debit Payment Amount
-10 10

Matching Logic

Basically, the automatic matching process compares all words (strings separated by spaces) that are contained in the Reference field of the payment entry with specified fields of matching target objects. The custom setting Payment Matching Fields determines which fields of which objects to consider, controlling the matching scope.

The matching process involves multiple passes.

The basic procedure compares the payment entry Reference content with invoice fields. To this end, JustOn ships pre-defined matching settings for the invoice number and the account number:

Name Field Active Source
Invoice Number Name (= Invoice No.) Invoice__c
Account Number Account__r.AccountNumber Invoice__c

Should this pass yield no results, a second one is performed: JustOn searches fields of related objects in order to find the correct invoice, like a customer number from the account.

Note that the order of the matching field definitions is irrelevant to the matching process. In the first pass, all invoice fields are examined, in the second pass all other fields.

For the payment matching to succeed,

  • avoid specifying multiple invoices per payment operation, and
  • prevent line breaks, space characters or semicolons from breaking the invoice number in the reference string.

Info

Importing payment entries as output by accounting systems (rather than bank statements) helps facilitate the payment matching in JustOn.

Usually, no customization is needed. Depending on your data or business requirements, you may need, however, to modify the matching logic. In this case, make sure that you use only fields that are set to be unique, that is, whose value can only exist once in your org. Otherwise you may produce poor results or break the matching logic.

For details about customizing the matching logic, see Payment Matching Fields.

In some cases, a payment entry may increase an open invoice amount, for example, with return debits or chargeback fees. Usually, JustOn does not match payment entries with invoices if this would increase the open invoice amount. You can, however, force JustOn to do so using the force matching option when executing the matching or assignment procedure.

Note

Use the force matching feature with caution. If enabled, the matching process may not yield the best result.

Consider the following example:

PaymentEntry: {Reference: ACC-12345 ..., PaymentAmount: 2088.12}
    Invoice1: {Account:ACC-12345, Name: AB-2013-00001, Balance: 2088.12}
    Invoice2: {Account:ACC-12345, Name: AB-2013-00002, Balance: -3088.12}

If the force matching feature is disabled, PaymentEntry definitely matches Invoice1.

With the force matching feature enabled, however, it is possible that PaymentEntry matches Invoice2.

CSV Import

You can import payment entries from CSV files produced by your bank. To match the CSV file's contents, you must specifically configure the import, specifying, among others, the file encoding, column separator, field mapping, etc.

CSV Import Configuration
Starting CSV Payment Data Import

figo Integration

JustOn integrates with figo to retrieve banking transactions, which are to be stored as payment entries.

figo
Retrieving banking transactions and creating payment entries

If set up accordingly, you can retrieve banking transactions for a specified account and a specified period from the bank server, which creates the corresponding payment entries. The field Payment Provider of the produced payment entries is set to figo.

JustOn checks existing balance records for the specified payment provider and transaction no. If Payment Provider is set to figo and the value of Transaction No. matches the value of Transaction No. of the retrieved payment entry, the balance record is considered a "figo balance" and therefore subject to the following procedure:

  • If there is already an existing balance record that matches the retrieved payment entry, JustOn sets the payment entry to the status Converted but does not create a new balance record. This prevents duplicate payment matching.
  • If the Is Deleted checkbox on the payment entry is selected and a balance object that matches the payment entry exists, JustOn deletes the balance record and sets the payment entry to the status Converted.

Enabling Data Retrieval From figo
Managing figo Banking Transactions

figo Filters

To filter the transactions to be retrieved, you can specify figo filters.

  • figo Transaction Filters control which types of banking transactions are to be transferred.
  • figo Transaction Content Filters filter the retrieved transactions by their content like name, reference, etc. This filter is an exclude filter, that is, retrieved transactions that match the filter conditions are not written to the database.

figo Filters

figo Data Conversion

figo stores banking transactions in the figo Connect Transaction object. Upon data transfer, JustOn automatically maps the retrieved transaction JSON data to the Payment Entry object.

The following table shows which data is written to the payment entry.

Payment Entry Field Value Description
ExternalTransactionId__c FIGO + <transaction_id> External ID that is used to uniquely match a figo transaction
TransactionNo__c <transaction_id> Internal figo transaction ID
PaymentProvider__c figo Name of the payment provider
Status__c New Status for newly created objects
Debit__c <amount> if the value is positive The debit amount
Credit__c <amount> if the value is negative The credit amount
Reference__c <purpose> Purpose text, can be empty if the transaction has no purpose
CustomerName__c <name> Name of originator or recipient
BankAccountId__c <account_id> Internal figo account ID
BookingDate__c <booking_date> Booking date
ProviderSpecificData__c complete transaction JSON data The retrieved figo transaction JSON data for this object

The figo Connect Transaction Object JSON data contains a number of additional fields. JustOn can write additional data values to custom fields of the payment entry. Each JSON value is processed in the following way:

(1) The JSON field name is converted to a Salesforce field name, where

  • underscores are removed,
  • if the JSON value belongs to a child object, the field name is prefixed with the field name of the parent object, connected by an underscore,
  • the string FIGO_ is prepended,
  • the string __c is appended.

(2) If there is a matching field on the Payment Entry object, the field value is written to this field.

(3) The type of the Payment Entry field must match the type of the JSON field value, like Text (255) for bank_name, Currency for amount or Date for value_date. JustOn automatically converts the JSON value to the type of the Payment Entry field.

Example field conversions

JSON Field Salesforce field name Type
account_number FIGO_AccountNumber__c Text (255)
value_date FIGO_ValueDate__c Date
end_to_end_reference FIGO_EndToEndReference__c Text (255)
additional_info.gross_amount FIGO_AdditionalInfo_GrossAmount__c Currency (13,5)

When retrieving figo transactions from the banking server, the response may contain a list of deleted transactions. For these transactions, JustOn also creates payment entries with the following data:

Payment Entry Field value Description
ExternalTransactionId__c FIGO + <transaction_id> External ID that is used to uniquely match a figo transaction
TransactionNo__c <transaction_id> Internal figo transaction ID
PaymentProvider__c figo Name of the Payment Provider
Status__c New Status for newly created objects
IsDeleted__c true Indicates that the corresponding transaction is deleted

Payment Collection

JustOn can store credit card data and use it to automatically collect payments for open invoices.

Info

The payment collection requires a payment provider integration with support for pre-authorized payment transactions.

The payment collection is available as of JustOn 2.53.

Implementation Details

The JustOn Self-Service Extension includes a payment page. It provides invoice recipients the option to pay their invoices. To this end, the JustOn Self-Service Extension integrates with payment service providers.

Depending on the payment provider you use, the JustOn Self-Service Extension can expose the Future Payments option on the payment page. Future payments make use of provider-specific means to pre-authorize and execute recurring charges (or other subsequent payments) without the need to repeatedly prompt users for card or account numbers.

With the future payments feature enabled, JustOn creates an account-specific Payment Instrument record, which holds the corresponding credit card or bank account information. The payment instrument records are accessible via the corresponding related list on the account detail page.

Based on the saved payment instruments, JustOn can execute payment runs in order to automatically collect pre-authorized payments.

Future Payments
Future Payment Notification

Payment Collection Workflow

In broad outline, the payment collection works as follows:

  • A first invoice is issued to the customer.
  • The customer pays for the invoice via credit card and allows to store the card data for future use.
  • A second invoice is issued to the customer: The customer is notified that the payment is collected automatically using the stored card data.
  • Once the payment due date has been reached, the payment run job collects the payment, creates a corresponding balance and sets the invoice Paid.

Scheduling Payment Collection

Settlements

JustOn can offset non-related invoices and credits of an account via settlements.

Think of a marketplace scenario: You sell products that are delivered by a participating organization. On the one hand, as you receive the customer's money, you have to pay out the vendor. To this end, you create a credit. On the other hand, you charge the vendor a commission for your brokerage, issuing an invoice. Now you can offset the invoice against the credit, thus settling the invoice and reducing the credit amount.

If set up accordingly, JustOn can settle open invoices or credits automatically with an invoice run. In addition, you can settle a single invoice or credit manually.

Generally, JustOn settles an open invoice against a new credit, and an open credit against a new invoice (also referred to as the settlement target).

For an open invoice or credit to be considered for settlement, its due date must be reached.

The settlement itself is implemented by balances on the open invoice and on the new (target) invoice. JustOn creates the balance of the type Settlement on the new invoice immediately when completing the settlement operation, irrespective of the invoice status (Draft or Open). When the new invoice is finalized (set Open), the open invoice to be settled gets the corresponding balance of the type Clearing, and at the same time, it is set Paid (in case of invoices) or Settled (in case of credits).

New invoice balance

Field Value
Type Settlement
Amount <settlement amount>
Related Invoice <settled invoice ID>

Settled invoice balance

Field Value
Type Clearing
Amount -1 * <settlement amount>
Related Invoice <new invoice ID>

Info

Invoices that are settled against a draft invoice cannot be settled against another draft invoice. Delete the settlement balance first.

The settled amount does not exceed the balance of the target invoice to avoid an overpayment.

Current Balance Target Balance Settled Amount Notes
-100 150 -100 full settlement of a credit against an invoice
-100 75 -75 partial settlement of a credit against an invoice
-100 -20 - no settlement possible
-100 0 - no settlement possible
0 20 - no settlement possible
100 -150 100 full settlement of an invoice against a credit
100 -75 75 partial settlement of an invoice against a credit
100 20 - no settlement possible
100 0 - no settlement possible
0 -20 - no settlement possible

Managing Settlements

Account Statements

To support accounting purposes, JustOn allows for generating account statements. An account statement represents a report that summarizes the balances of a given account for a specific time period. PDF copies of the account statements can then be distributed to the corresponding recipients.

Account statements can have different statuses.

  • Draft: New account statements have the status Draft. You can check draft account statements for correctness and edit them as necessary.
  • Closed: Finalizing account statements sets them to Closed and generates the PDF account statements to be sent out.

There are two ways to create account statements:

  • individually for a single account using the function Account Statement,
  • for multiple accounts using the Statement Runs functionality.

After reviewing them, you can then distribute the generated account statements.

Finished account statements, that is, those in the status Closed, are supposed to be distributed to their corresponding recipients.

  • By default, JustOn supports the distribution of the generated account statement PDF documents via email.
  • You can redistribute account statement PDF documents to new file distribution target or download them to a ZIP file.

    Use the redistribution function with caution. JustOn does not check the selected file distribution target for existing files, so distributing the same files to the same targets produces duplicates, which may consequently have unwanted effects.

Managing Account Statements
Setting Up Account Statement Management

Dunnings

To help tracking and claiming outstanding payments, JustOn supports dunning processes. With this respect, the following objects are important:

Statements represent the dunning statements that document outstanding payments, based on which you generate dunning reminders to be sent out to the corresponding accounts. The dunning records are associated to the relevant accounts and hold the corresponding data as well as payment information.

Statement details represent the individual items to which the dunning refers - the actual invoices and, if set up accordingly, the dunning fees. Dunning details are in a master-detail relationship to a dunning.

A dunning run can include multiple invoices per account, producing an individual statement detail for each involved invoice. Consequently, an invoice that is subject to a dunning process relates to the produced statement detail, but not to the statement.

dunning
Dunning reminder that involves two invoices

Basically, the dunning process involves three main steps:

  • Dunning run: You create draft dunnings for open invoices or account statements.
  • Finalizing: You close the dunnings and generate the dunning reminder PDF documents.
  • Distribution: You send out the dunning reminders via email.

The dunning run refers to the operation that creates dunning notifications. The statements issued with the dunning run are referred to as dunnings. Depending on the progress of the dunning process, they can have different statuses.

  • Draft: New dunnings have the status Draft. You can check draft dunnings for correctness and edit them as necessary.
  • Closed: Finalizing dunnings sets them to Closed, generates the PDF dunning reminders to be sent out, and adds the defined dunning fees to the account balance and the open invoice amount. As a whole, this makes the dunning operation legally effective.

In order to use the dunning process feature, you must configure it accordingly using the custom setting Dunning Levels. This setting defines, among others,

  • the condition to be matched for activating the process,
  • dunning fees and late fees as required,
  • the due period and a grace period.

Using multiple dunning levels, you can build your individual dunning escalation scenario, which may progress from friendly reminders to firm warning letters.

Once set up, you can then start a dunning run using the Statement Runs functionality.

Finished dunning reminders, that is, those in the status Closed, are supposed to be distributed to their corresponding recipients.

  • By default, JustOn supports the distribution of the generated dunning reminder PDF documents via email.
  • You can redistribute dunning reminder PDF documents to new file distribution target or download them to a ZIP file.

    Use the redistribution function with caution. JustOn does not check the selected file distribution target for existing files, so distributing the same files to the same targets produces duplicates, which may consequently have unwanted effects.

Managing Dunning Reminders
Setting Up Dunning Process Management

Bookkeeping Data for Invoices

JustOn allows for writing bookkeeping data for finalized invoices. These records can then be transferred to bookkeeping systems like DATEV or SAP.

Enabling Bookkeeping Data Generation

Invoice Bookkeeping Data Structure

Bookkeeping data is structured in booking periods and booking details. Booking periods and booking details are in a master-detail relationship.

Booking Period

A booking period represents one month in bookkeeping. Hence, they aggregate the booking details produced for this month. Booking periods are grouped by tenants.

The following fields are available:

Field Data Type Possible Values Required Description
Name Text The booking period name, is set automatically using this pattern:
TENANT-YEAR-MONTH (w/ tenant)
YEAR-MONTH (w/o tenant)
Month Picklist 01, 02 ... 12 The month for the booking period.
Year Text (4) 2017 The year for the booking period.
Tenant Text (255) The tenant for the booking period.
Status Picklist Open
Closed
The booking period status: A closed booking period is ignored when finalizing the invoice, any matching details for this period are moved to the next open period.

Booking Details

A booking detail represents a record in an accounting ledger. By default, JustOn creates one booking detail per invoice line item. For other options, see Revenue Recognition.

Booking detail fields and source fields
Field Required Source Fields Description
Name The booking detail name, is set automatically based on the type using these patterns:
Revenue: ACCOUNTNUMBER-INVOICENUMBER
Tax: TAXRATE-INVOICENUMBER
Account Invoice.Account The account for the booking detail.
Account Name Invoice.AccountName The account name as taken from the invoice.
Account Number InvoiceLineItem.GLAccount The general ledger account as taken from the invoice line item.
Business Partner Account Number Account.ON_DebtorNo
CollectiveAccount.BpAccountNo
Either the debtor/creditor (contra account) number if the field ON_DebtorNo on the account is available, or the business partner account number as taken from the Collective Accounts custom setting.
Amount InvoiceLineItem.PosTotalNet
InvoiceLineItem.PosTotalTax
The amount of the booking detail; Revenue is taken from PosTotalNet and Tax is taken from PosTotalTax of the invoice line item.
IsGross Is set to true for Revenue Details if Enable Accounting in Gross Values is enabled (see Enabling Bookkeeping Data Generation) and the amount is inclusive of taxes.
Balance The source balance for booking details of the type Payment.
Bank Account Owner Invoice.BankAccountOwner The bank account owner as part of the banking data.
BIC Invoice.BankCode The bank code/BIC as part of the banking data.
Billing City Invoice.BillingCity The billing city as taken from the invoice.
Booking Date Invoice.ON_BookingDate
Invoice.Date
The booking date is derived from the invoice Date field or, if configured, from ON_BookingDate.
For non-tax details, the booking date is further adjusted to the first day of the month. Optionally, it can be set to the last day of the month. To this end, you activate the global setting Use End of Month as Booking Date.
If the booking detail is to be moved to the next open booking period, JustOn applies the date of the target booking period to the booking detail.
Booking Period The booking period as determined by the booking date.
Center InvoiceLineItem.Center The cost center or profit center for this booking detail.
Export Destination The export target, is set automatically upon export.
Exported Selected automatically upon export completion.
IBAN Invoice.BankAccount The bank account/IBAN as part of the banking data.
Invoice Invoice.Id The source invoice for booking details of the types Revenue and Tax.
Invoice Line Items InvoiceLineItem.Name A comma separated list of the invoice line items that have been used to build this booking detail
Invoice No The invoice number as taken from the invoice via a formula.
Recognition Rule InvoiceLineItem.RecognitionRule The recognition rule that has been used to create this booking detail.
Last Error Shows export errors, is set automatically upon export.
Tax Rate InvoiceLineItem.TaxRate The tax rate of the invoice line item.
Tax Rule InvoiceLineItem.AppliedTaxRule The applied tax rule of the invoice line item.
Type The booking detail type; possible values include Revenue, Tax (set based on invoices) and Deferred.
VAT ID Account.TaxNumber The VAT identifier of the related account.

JustOn can copy additional fields from the invoice or an invoice line item to the booking details. All additional fields on the booking detail invoke a copy operation. JustOn first tries to copy data from the invoice, then from the invoice line item.

Booking Detail Field Invoice Field Invoice Line Item Field Result
Billing Country Billing Country n/a copy from invoice to booking detail
Discount n/a Discount copy from invoice line item to booking detail
Duplicate Duplicate Duplicate copy from invoice line item to booking detail

For additional technical information about the booking detail fields (API names, data types, etc.), see the Booking Detail object reference.

Bookkeeping data for cancellation invoices

If the bookkeeping data generation is enabled, JustOn creates booking details as follows when finalizing a cancellation invoice:

  • For each existing booking detail of the cancelled invoice, JustOn creates a new, "opposite" booking detail.
  • For booking details of the type Revenue, JustOn appends the related account number to the name of the new booking detail.
  • For the amount of the new booking detail, JustOn sets the inverted amount of the existing booking detail.

Applying Revenue Recognition

JustOn ships a number of revenue recognition rules. They control the way invoices and invoice line items are transformed into booking details.

JustOn determines the revenue recognition rule to be applied via the invoice line item field Recognition Rule. If the field is not set, JustOn uses the Default rule.

Info

You can use the ON field mechanism, Salesforce processes or other automation tools to have the recognition rule set automatically on the invoice line item when generating invoices.

The following revenue recognition rules are available:

Recognition Rule Description
Default Creates one booking detail per invoice line item. The booking date is taken from the field ON_BookingDate of the invoice. The invoice date is used as fallback.
Monthly Creates multiple booking details that are evenly distributed over the service period of the invoice line item. The service period of the invoice is used as fallback.
If the service period does not start at the beginning or end at the end of a month, the booking amount is calculated proportionally for this month.
If the booking amount does not divide evenly and requires the split amounts to be rounded down, the remainder is added to the first booking detail. For example, 49,99 split into four parts results in 12,52 + 12,49 + 12,49 + 12,49.
The Monthly recognition rule is available as of JustOn 2.49.
Shortfall Creates two booking details if a defined minimum price exceeds the actually incurred costs: one for actually incurred costs, and another one for the shortfall amount, that is, the difference between the actually incurred costs and the defined minimum price.
The Shortfall recognition rule is available as of JustOn 2.52.
Service Period Creates one booking detail per invoice line item. The booking date is taken from the service period start of the invoice line item.
If you use deferred revenue bookings, JustOn creates additional Deferred booking details: one with the booking date taken from the booking date of the invoice (or the invoice date as fallback), and one with the booking date taken from the service period start of the invoice line item.
The Service Period recognition rule is available as of JustOn 2.59.

Bookkeeping Data Generation

If the bookkeeping data generation is enabled, JustOn splits invoices and their invoice line items upon finalization, producing several booking details. This is a three-step process:

(1) Creating booking details

(2) Assigning booking details to booking periods

(3) Combining booking details

The booking detail generation examples below illustrate the default booking detail generation and the revenue distribution using the Monthly recognition rule.

(1) Creating Booking Details

If enabled, JustOn creates booking details upon invoice finalization.

Depending on your business or accounting requirements, you can create booking details applying either the Default, Monthly or Shortfall recognition rule. The rule is determined via the invoice line item field Recognition Rule. If the field is not set, JustOn uses the Default recognition rule.

Irrespective of the recognition rule, JustOn creates separate booking details for the taxes of an invoice line item. The booking date is taken from the invoice line item field ON_BookingDate, with the invoice date as fallback. Be aware that if you use gross values when creating bookkeeping data (see Enabling Bookkeeping Data Generation), JustOn does not create tax details.

(2) Assigning Booking Details to Booking Periods

Each booking detail is assigned to a booking period. The Booking Date is used to determine the target period. If the target period does not yet exist, it is created automatically. If the period is closed, the booking detail is assigned to the next open period.

(3) Combining Booking Details

JustOn combines booking details that are assigned to the same booking period if the following data match:

Info

The field InvoiceLineItems of the booking detail contains a comma separated list of the invoice line items that have been used to build this booking detail.

Booking Detail Generation Examples

Default recognition rule

Consider the following example: One invoice with four invoice line items and the Default recognition rule results in four booking details, split by G/L account and revenue/tax.

Invoice line items

# G/L Account Pos Total Net Pos Total Tax Tax Rate Invoice No.
1 0001 10,00 0,70 7% R12345
2 0001 20,00 1,40 7% R12345
3 0002 30,00 5,70 19% R12345
4 0002 40,00 7,60 19% R12345

Resulting booking details

# Type Account No. Amount Tax Rate Name
1 Revenue 0001 30,00 7% 0001-R12345
2 Revenue 0002 70,00 19% 0002-R12345
3 Tax 2,10 7% 7.0-R12345
4 Tax 13,30 19% 19.0-R12345

booking_details.png
Booking details split by G/L account and revenue/tax with Default recognition rule

Combined Default/Monthly recognition rule

Now assume, in addition, that the invoice's service period covers ten months and that the fourth invoice line item is subject to the Monthly recognition rule. The same invoice line items on the invoice will now produce 14 booking details: additional 10 for the item's revenue portions, which are to be distributed over 10 months. The item's tax is not split, and, following the example, combined with the 19% tax of item #3.

# Type Account No. Amount Tax Rate Name
1 Revenue 0001 30,00 7% 0001-R12345
2 Revenue 0002 30,00 19% 0002-R12345
3..12 Revenue 0002 4,00 19% 0002-R12345
13 Tax 2,10 7% 7.0-R12345
14 Tax 13,30 19% 19.0-R12345

booking_details_monthly.png
Booking details split by G/L account and revenue/tax with combined Default/Monthly recognition rule

Combined Default/Monthly recognition rule with gross values

Now consider the following additional condition: You create gross booking details (for example, when using automatic accounts in DATEV), and enable the tax aggregation. That is, you select the options Enable Accounting in Gross Values and Accounting Gross Taxes on First Month. Consequently, your booking details are not split by revenue/tax, only by G/L account and by booking period according to the Monthly recognition rule.

The four invoice line items

# G/L Account Pos Total Gross Recognition Rule Tax Rate Invoice No.
1 0001 10,70 Default 7% R12345
2 0001 21,40 Default 7% R12345
3 0002 35,70 Default 19% R12345
4 0002 47,60 Monthly 19% R12345

produce 12 booking details:

# Type Account No. Amount Tax Rate Name
1 Revenue 0001 32,10 7% 0001-R12345
2 Revenue 0002 35,70 19% 0002-R12345
3 Revenue 0002 11,60 19% 0002-R12345
4..12 Revenue 0002 4,00 19% 0002-R12345

The complete tax amount for invoice line item #4 is added to the first corresponding booking detail (#3). The remaining booking details (#4..12) represent net values.

booking_details_gross_monthly
Gross booking details split by G/L account with combined Default/Monthly recognition rule

Handling Shortfall Amounts

JustOn can generate separate booking details for so-called shortfall amounts - the difference between some actually incurred costs and the defined minimum price.

Consider the following use case: You invoice usage costs with a fixed minimum base price. That is, you combine usage data billing with price tiers, where the first tier has defined a flat price. Now assume that the actually achieved quantity of an item is smaller than the quantity for the flat price tier. You invoice the flat price, but your accounting may need to separately track a) the revenue resulting from the actual consumption and b) the revenue resulting from the difference billed by implication. To support this scenario, you apply the recognition rule Shortfall.

Info

Shortfall amount handling is available as of JustOn 2.52.

The Shortfall recognition rule requires the following invoice line item fields in particular:

Field Description
Base Quantity The actually achieved quantity, determined via usage data billing.
Quota Quantity The quantity specified for the flat price tier.
GL Account The G/L account used for the revenue resulting from the actual consumption. The value is taken from the G/L Account field of the Assignment Rules - G/L Account custom setting.
GL Account 2 The second G/L account, used for the revenue resulting from the shortfall amount. The value is taken from the G/L Account 2 field of the Assignment Rules - G/L Account custom setting.

JustOn applies the Shortfall recognition rule if the following conditions are met:

(1) The fields Base Quantity and Quota Quantity of the invoice line item are set, which implies

  • a price tier with the price type Flat
  • usage data billing properly set up to determine the actual quantity

(2) The value of Quota Quantity is higher than the value of Base Quantity.

(3) The field Recognition Rule of the invoice line item is set to Shortfall.

If the conditions are not met, JustOn uses the recognition rule Default.

Now if enabled and set up accordingly, JustOn creates two booking details when finalizing the invoice:

  • one for the revenue that results from the tracked product consumption
  • a second one for the revenue that results from the shortfall amount, that is, the difference between the actually incurred costs and the defined minimum price

    Make sure you have two G/L accounts set in GL Account and GL Account 2.

The invoice line item total (the defined minimum flat price) is split proportionally according to the determined quantity, as illustrated in the following example:

Price tier:

Quantity Price Price Type
500 1000,00 Flat

With an actual consumption of 400, the invoice line item has the following quantity information:

Field Value
Base Quantity 400
Quota Quantity 500

Applying the proportional distribution, this produces the following booking details:

# Booking Account Calculation Amount
1 G/L Account (400 / 500) * 1000,00 800,00
2 G/L Account 2 (100 / 500) * 1000,00 200,00

Handling Deferred Revenue

Your accounting may require to book deferred revenue to a dedicated account. This may be the case if you distribute the revenue of an invoice over multiple booking periods using the Monthly revenue recognition rule. Consequently, the revenue amount booked during the defined period is "taken out" from the deferred revenue account.

Info

Deferred revenue handling is available as of JustOn 2.52.

For JustOn to generate a booking detail for the deferred revenue, you must create a corresponding Collective Accounts custom setting.

Consider the following example: There is an invoice whose amount is to be distributed equally to four booking periods using the Monthly recognition rule.

Field Value
Pos Total Net 1000€
Tax 190€
Grand Total 1190€
Service Period Start 2018-05-01
Service Period End 2018-08-31

Now assume that your accounting requires the deferred revenue to be booked to the account 2500. To this end, you create the following collective account setting:

Field Value
Name Deferred Revenue
Type Deferred
Account 2500

Accordingly, JustOn generates the following booking details upon invoice finalization:

# Booking Period Type Amount Notes
1 2018-05 Tax 190 The tax is always booked in the first booking period.
If there is a corresponding collective account setting for taxes, it specifies the account number.
2 Revenue 250 1/4 of the revenue is booked in the first booking period.
The account number is taken from a corresponding G/L accounts setting.
3 Deferred 750 3/4 of the revenue is booked to the deferred revenue account in the first booking period.
The account number is taken from the corresponding collective account setting ( 2500).
4 2018-06 Revenue 250 1/4 of the revenue is booked in the second booking period.
5 Deferred -250 1/4 of the revenue is taken out from the deferred revenue account to offset the booked revenue in the second booking period.
6 2018-07 Revenue 250 1/4 of the revenue is booked in the third booking period.
7 Deferred -250 1/4 of the revenue is taken out from the deferred revenue account to offset the booked revenue in the third booking period.
8 2018-08 Revenue 250 1/4 of the revenue is booked in the fourth booking period.
9 Deferred -250 1/4 of the revenue is taken out from the deferred revenue account to offset the booked revenue in the fourth booking period.

Service Period-Based Bookings

JustOn can generate booking details where the booking date is taken from the service period start date of the invoice line item instead of the billing date. To support this scenario, you apply the recognition rule Service Period.

Info

The support for service period-based booking details is available as of JustOn 2.59.

Assume the following example: There is an invoice with the booking date 2019-03-01 and the following invoice line items:

# Quantity Price Tax Service Period Start Service Period End
1 1 1000,00 19% 2019-03-01 2019-06-30
2 1 1000,00 19% 2019-05-01 2019-08-31

Using the Service Period recognition rule produces the following booking details:

# Booking Date Amount Type
1 2019-03-01 1000,00 Revenue
2 2019-03-01 190,00 Tax
3 2019-05-01 1000,00 Revenue
4 2019-05-01 190,00 Tax

If you use the Service Period recognition rule in combination with deferred revenue bookings, JustOn creates additional Deferred booking details: one with the booking date taken from the booking date of the invoice (or the invoice date as fallback), and one with the booking date taken from the service period start of the invoice line item. To this end, the following conditions must be met:

(1) The billing date is before the service period start date of the invoice line item.

(2) Deferred revenue booking is enabled.

The following example illustrates this behavior:

There is an invoice with the booking date 2019-03-01 and the following invoice line item:

Quantity Price Tax Service Period Start Service Period End
1 1000,00 19% 2019-05-01 2019-08-31

Using the Service Period recognition rule, combined with deferred revenue booking, produces the following booking details:

# Booking Date Amount Type
1 2019-03-01 1000,00 Deferred
2 2019-03-01 190,00 Tax
3 2019-05-01 1000,00 Revenue
4 2019-05-01 -1000,00 Deferred

Payment Date-Based Tax Bookings

Your accounting may require to book taxes at the payment date. To support this scenario, you can force JustOn to move tax booking details to the payment date.

Info

The support for payment date-based tax booking is available as of JustOn 2.59.

Enabling the corresponding global setting Move Tax Booking Details to Payment Date activates the following behavior:

  • When creating tax booking details using the recognition rule Monthly, JustOn moves them to the last month of the invoice service period.
  • When registering a payment on the invoice, JustOn moves all tax booking details to the month of the payment date.

The following conditions for tax details apply:

  • Tax details must have a positive amount.
  • The booking period must be open.
  • The tax detail is not exported.
  • The month of the payment date must precede the current tax detail booking date.

Enabling Payment Date-Based Tax Bookings

Regenerating Booking Details

Certain business use cases may require to regenerate booking details, for example, when the configuration was incorrect (G/L account, cost center, recognition rule, etc.), or when the bookkeeping data generation was not enabled on invoice finalization. JustOn allows to use the Invoice Import and Fix Feature to regenerate booking details as they have not been exported.

When regenerating booking details, JustOn

  • deletes existing booking details,
  • creates new booking details and assigns them to booking periods in the same way as for the invoice finalization, but with the current configuration.

Note

If one of the existing booking details of an invoice is already exported, JustOn will skip the invoice completely and will not regenerate any booking details for this invoice.

Info

Regenerating booking details of a cancelation invoice processes the booking details of the related canceled invoice. Hence, make sure that the related canceled invoice is correct before staring the fix invoice process for the cancelation invoice.

Enabling Booking Detail Regeneration

Bookkeeping Data for Payment Balances

With the figo integration and the ability to capture payments from various payment providers via the Self-Service Extension, JustOn is becoming a leading system to receive payment information. Accordingly, it allows for writing bookkeeping data for payment balances. These records can then be exported to bookkeeping systems like DATEV or SAP.

Ideally, you generate bookkeeping data from payment balances on a daily basis. To this end, JustOn provides a dedicated scheduled job. Once generated, you can export the bookkeeping data to accordingly configured CSV files, like DATEV posting batch or SAP CSV, which can then be transferred to the corresponding accounting system.

Info

The support for generating bookkeeping data from payment balances is available as of JustOn 2.57.

Bookkeeping data as generated from payment balances can hold account numbers, which are, typically, debtor numbers and bookkeeping accounts related to bank accounts or payment provider accounts. The data is able to track changes made to payment balances, like amount change or deletion. Payment bookkeeping data is unalterable with regard to balance assignment and overpayment splitting in order to keep the data clean.

Enabling Bookkeeping Data Generation
Scheduling Payment Bookkeeping Data Generation

Payment Bookkeeping Data Structure

Bookkeeping data is structured in booking periods and booking details. Booking periods and booking details are in a master-detail relationship.

A booking period represents one month in bookkeeping. Hence, they aggregate the booking details produced for this month. Booking periods are grouped by tenants.

A booking detail represents a record in an accounting ledger. JustOn creates one booking detail per payment balance change.

The following fields are mapped from the balance to the booking detail:

Balance Field Booking Detail Field
Account Account
Amount Amount
Date Booking Date, Payment Date
Type Type
Id Balance

Workflow

JustOn generates booking details for balances of the following types: Payment, Refund, Prepayment, Payout, Write-off. All other balance types are ignored.

Since payment balances are subject to change, like amount modification, deletion or splitting, JustOn does not track payment balances and booking details in a one-to-one relationship, but uses a payment hash instead. The following Balance fields are used to compute the hash: Account, Date, Payment Method, Payment Provider, Reference, Transaction No and Type. This means, all balances where these fields have the same value are aggregated to the same booking detail.

Info

JustOn uses the Booking Detail field Balance to link back to the first balance. This does not guarantee, however, its accuracy in case of a balance split or recombination. Use this field for information or navigation purposes only.

The bookkeeping data creation does not update existing payment booking details. JustOn always creates a new booking detail record to track an individual payment balance change.

JustOn tracks amount modifications to existing balances as new booking details with a new amount. That is, a change by a delta of 5,00 EUR results in a new booking detail with an amount of 5,00 EUR.

Deleted balances are written off: JustOn creates a new booking detail, reverting the amount, like Amount * (-1).

Assigning Bookkeeping Accounts

With booking details created from payment balances, the field Account Number specifies the bookkeeping account number of the bank account or payment provider.

The field Business Partner Account Number specifies the debtor number of the related account. The field is filled upon booking detail generation if the custom Account field ON_DebtorNo has beed configured and set accordingly.

You can use the collective accounts feature to provide both the G/L account and business partner account for the bookkeeping data creation.

Handling Provider Fees

Provider fees are tracked on the balance using the field Provider Fee. Some payment provider integrations may also define the custom formula field ON_ProviderFee for calculating the provider fees. If the field is not available or empty, JustOn uses the standard Provider Fee field.

If JustOn detects a provider fee when generating the bookkeeping data, it will create an individual booking detail of the type Provider Fee. You can move these booking details to separate bookkeeping accounts using the collective accounts feature.

Handling Tenants

If a balance is associated with an invoice, JustOn takes the tenant of the invoice to determine the correct booking period. If a balance is unassigned, the tenant is determined from the customer account using a tenant mapping.

Correction booking details, like for an amount modification or a deletion, always use the tenant of the original booking detail.

Payment Booking Details Examples

The following examples show how JustOn writes booking details for payment balances and tracks further changes on involved balances.

Receiving PayPal payment with provider fee

Assume the following actions:

  • Customer pays via the payment page with PayPal
  • Payment balance is created and assigned to the account and invoice
  • Invoice is set Paid
  • Booking detail is created from payment balance

This produces two booking details with the following information:

Field Example Value Description
Name 2019-01-15-12345 Concatenation of payment date and debtor number (with fallback to the account name).
Amount -100 Taken from the Balance field Amount.
Payment Date 2019-01-15 The date of the payment transaction.
Booking Date 2019-01-15 The booking date may be different from the payment date if the target booking period is closed and the booking detail has been moved.
Payment Hash abc123 Calculated by JustOn in order to track changes on involved balances.
Type Payment Taken from the Balance field Type.
Balance - Links to the associated balance.
Account No 12345 The G/L account, taken from the Account field ON_DebtorNo, can be set by collective account rules if it is empty or not available.
Business Partner Account No 67890 The contra account, set by collective account rules.
Field Example Value Description
Name 2019-01-15-76543 Concatenation of payment date and G/L account number (with fallback to the account name).
Amount 2,75 Taken from the Balance fields ON_ProviderFee or Provider Fee.
Payment Date 2019-01-15 The date of the payment transaction.
Booking Date 2019-01-15 The booking date may be different from the payment date if the target booking period is closed and the booking detail has been moved.
Payment Hash xyz987 Calculated by JustOn in order to track changes on involved balances.
Type Provider Fee Set by JustOn.
Balance - Links to the associated balance.
Account No 34567 Set by collective account rules.
Business Partner Account No 98765 Set by collective account rules.
Importing payment entries from figo with manual assignment

Assume the following actions:

  • Import payment entries from figo, match to account
  • Manually assign balance to the next open invoice

The bookkeeping data can be generated before or after the invoice assignment. The result is the same.

Field Example Value Description
Name 2019-01-15-12345 Concatenation of payment date and debtor number (with fallback to the account name).
Amount -75 Taken from the Balance field Amount.
Payment Date 2019-01-15 The date of the payment transaction.
Booking Date 2019-01-15 The booking date may be different from the payment date if the target booking period is closed and the booking detail has been moved.
Payment Hash def567 Calculated by JustOn in order to track changes on involved balances.
Type Payment Taken from the Balance field Type.
Balance - Links to the associated balance.
Account No 12345 The G/L account, taken from the Account field ON_DebtorNo, can be set by collective account rules if it is empty or not available.
Business Partner Account No 67890 The contra account, set by collective account rules.
Manual balance with amount change, debtor number not available

Assume the following actions:

  • Register partial payment on invoice
  • Generate bookkeeping data
  • Change amount of partial payment
  • Generate bookkeeping data

The first booking detail creation:

Field Example Value Description
Name 2019-01-15-Foo Inc. Concatenation of payment date and fallback to the account name (no debtor number available).
Amount -35 Taken from the Balance field Amount.
Payment Date 2019-01-15 The date of the payment transaction.
Booking Date 2019-01-15 The booking date may be different from the payment date if the target booking period is closed and the booking detail has been moved.
Payment Hash asd84578 Calculated by JustOn in order to track changes on involved balances.
Type Payment Taken from the Balance field Type.
Balance - Links to the associated balance.
Account No 1111 Set by collective account rules.
Business Partner Account No 2222 Set by collective account rules.

From the second bookkeeping data creation results a booking detail that covers the amount change:

Field Example Value Description
Name 2019-01-15-Foo Inc. Concatenation of payment date and fallback to the account name (no debtor number available).
Amount 5 Calculated as follows: new amount minus original amount (like -30 - (-35) = 5).
Payment Date 2019-01-15 The date of the payment transaction.
Booking Date 2019-02-01 Moved to the next booking period, since the original booking period has been closed.
Payment Hash asd84578 The same hash as for the original booking detail.
Type Payment Taken from the Balance field Type.
Balance - Links to the associated balance.
Account No 1111 Set by collective account rules.
Business Partner Account No 2222 Set by collective account rules.
Manual balance with deletion

Assume the following actions:

  • Register partial payment on invoice
  • Generate bookkeeping data
  • Delete partial payment
  • Generate bookkeeping data

The first booking detail creation:

Field Example Value Description
Name 2019-01-15-Foo Inc. Concatenation of payment date and fallback to the account name (no debtor number available).
Amount -35 Taken from the Balance field Amount.
Payment Date 2019-01-15 The date of the payment transaction.
Booking Date 2019-01-15 The booking date may be different from the payment date if the target booking period is closed and the booking detail has been moved.
Payment Hash klm654 Calculated by JustOn in order to track changes on involved balances.
Type Payment Taken from the Balance field Type.
Balance - Links to the associated balance.
Account No 1111 Set by collective account rules.
Business Partner Account No 2222 Set by collective account rules.

From the second bookkeeping data creation results a booking detail that covers the balance deletion:

Field Example Value Description
Name 2019-01-15-Foo Inc. Concatenation of payment date and fallback to the account name (no debtor number available).
Amount 35 Calculated as follows: original amount multiplied by -1 (like -35 * (-1) = 35).
Payment Date 2019-01-15 The date of the payment transaction.
Booking Date 2019-02-01 Moved to the next booking period, since the original booking period has been closed.
Payment Hash klm654 The same hash as for the original booking detail.
Type Payment Taken from the Balance field Type.
Balance - Links to the associated balance.
Account No 2222 The original business partner account number.
Business Partner Account No 1111 The original G/L account number.

Bookkeeping Data for Subscriptions

Depending on your business, you can bill items at the end of their service period, setting the field Billing Practice to Invoicing in arrears (see Item-Specific Billing Practice). Your accounting, however, may still require bookkeeping data for those items before they are actually billed. To support this scenario, JustOn can generate preliminary bookkeeping data based on subscriptions. Consequently, when creating and finalizing the corresponding invoices, the existing subscription bookkeeping data is assigned to the invoice. Possible differences between the subscription booking details and the produced invoice data are cleared using according correction booking details.

Info

The support for subscription bookkeeping data is available as of JustOn 2.58.

Note

Subscription bookkeeping data do not support accounting in gross values. That is, you cannot use automatic accounts in DATEV for bookkeeping data produced from subscriptions.

Enabling Bookkeeping Data Generation
Creating Subscription Bookkeeping Data Processes

Subscription Bookkeeping Data Structure

Bookkeeping data is structured in booking periods and booking details. Booking periods and booking details are in a master-detail relationship.

A booking period represents one month in bookkeeping. Hence, they aggregate the booking details produced for this month. Booking periods are grouped by tenants.

A booking detail represents a record in an accounting ledger. JustOn creates one booking detail per subscription item. Basically, it holds the same data as a booking detail produced from an invoice line item, except for

  • Invoice
  • Invoice Line Items
  • Invoice No

These fields are not set since there is no invoice produced yet.

Subscription Bookkeeping Data Workflow

JustOn "simulates" an invoice run per month to create the subscription bookkeeping data. It generates booking details for subscription items of the following types: Recurring, Recurring Prorated, One-Time and Minimum Fee. Transactional items are ignored.

With respect to the subscription bookkeeping data generation, be aware of the following specifics:

  • Subscription bookkeeping data is always created without taxes. That is, you cannot use automatic accounts in DATEV for bookkeeping data produced from subscriptions.
  • Subscription bookkeeping data is always created on a monthly base. That is, they may differ from the invoice bookkeeping data if you use longer (or shorter) billing periods or invoice run periods. JustOn makes sure, however, that the correction booking details clear any differences upon invoice finalization.
  • Since there is no active invoice, subscription bookkeeping data does not consider deferred revenue.
  • If there is no start date set (neither for the subscription nor for the item), JustOn uses the current date as the start date.
  • If there is no end date, the bookkeeping data is generated for one year.
  • For periods for which invoices have already been issued, JustOn does not generate subscription bookkeeping data.

JustOn stores the start date for the next booking detail generation in the Item field Next Booking Detail Start. This field is used to determine the start date for generating new booking details if the bookkeeping data creation is started for a modified subscription, for example, after adding new items or on subscription renewal.

JustOn does not update existing subscription bookkeeping data. If, for example, you modify the price of an item before creating the invoice, JustOn will clear the difference by creating a correction booking detail when creating and finalizing the invoice.

Info

JustOn recommends to create a report to detect subscription booking details that are not yet assigned to an invoice after the accounting year has expired. Possible findings may indicate, for example, that there were some invoices not created or finalized, or that you need to manually clear bookkeeping accounts.

Booking Account Allocation

Accounting systems like DATEV or SAP allocate booking data to dedicated bookkeeping accounts. To facilitate the initial account allocation, JustOn supports

G/L Account and Center

Your organization's business may require to export bookkeeping data for invoices to accounting systems like DATEV or SAP. Usually, these systems assign generated revenues to general ledger accounts (G/L accounts, structures that record value movements in defined contexts) or cost centers or profit centers (business subdivisions to which costs or profits are allocated).

To support these assignments, JustOn can add G/L account or center information to invoice line items. When generating the bookkeeping data, this information is then populated to the booking details accordingly.

Info

JustOn always recalculates the G/L Account and Center fields when doing a database update on the invoice line item. By default, this happens during the invoice creation or the invoice finalization.

Updating open invoices

If you need to update an invoice that is already set Open with additional or new G/L account or center data, use JustOn's invoice fixing functionality, clicking Fix Invoices as described in Invoice Import and Fix. If that fails, perform a database update on the invoice line items of the selected invoices with the appropriate admin tools, like the Data Loader or the Force.com Workbench.

You can control which G/L account or center information is added to invoice line items using specific assignment rules. JustOn implements these assignment rules as two custom settings:

  • Assignment Rules - Center: Define the criteria (fields and values to match) based on which an invoice line item is assigned a cost center or profit center.
  • Assignment Rules - G/L Account: Define the criteria (fields and values to match) based on which an invoice line item is assigned a G/L account.

When working with assignment rules, be aware of the following:

  • The rule matching process yields the specified result only if all specified criteria match. If you specify, for example, a product group and a tenant, the rule applies only if both the tenant on the invoice and the product group on the invoice line item have the corresponding values.
  • If a rule field is empty, it is ignored during the matching process. If you specify, for example, a tenant, the rule applies if the tenant on the invoice has the corresponding value. Other data, like the product group, have no effect in this case.
  • If you use multiple rules, the same fields must be filled (or empty) in all rules. If you specify, for example, a product group in one rule, you must specify a product group in all other rules, too. Otherwise, if you leave a field empty in one rule, the field must also be empty in all other rules.

    In case of ambiguous rule sets, the assignment becomes random.

Assignment Rules - Center
Assignment Rules - G/L Account

Collective Accounts

Depending on your business processes, you may create specific booking details that are not assigned to a G/L account. Accounting systems like DATEV or SAP, however, usually require an account number. To handle these scenarios, you can use collective accounts. They define account numbers for booking details without dedicated account numbers - primarily, for taxes or deferred revenues, but also for other use cases like payment bookkeeping data.

JustOn implements collective accounts using the custom setting Collective Accounts.

Collective Accounts

Contra Accounts

In double-entry bookkeeping, every entry to an account requires a corresponding opposite entry to a contra account (also known as offsetting account), which is credited to offset a debit or debited to offset a credit. To support this scenario, JustOn can copy the contra account number from the optional Account field ON_DebtorNo to the Booking Detail field Business Partner Account Number. In this context, the business partner represents a debtor or creditor, and hence, the contra account.

Info

The support for contra account numbers is available as of JustOn 2.57.

Enabling Contra Accounts for Invoice Bookkeeping Data
Enabling Contra Accounts for Payment Bookkeeping Data

Center Split

Your business may require to distribute the amount of one or more booking details of the type Revenue over multiple centers. To cover this need, JustOn provides the functionality to manually split or combine these booking details.

Managing Booking Detail Center Split

SEPA Export

Your organization's business may require to export bank transfer orders for invoices. These payment orders can then directly be used by banks for triggering the corresponding payment operations.

JustOn supports two common implementations of (interchangeable) bank transfer orders:

For invoices whose payment method is either Bank Transfer or Direct Debit, you can produce SEPA XML files for debits and credits using the invoice export mechanism.

SEPA Direct Debit

JustOn exports SEPA Direct Debit orders for invoices if

  • the payment method is either Bank Transfer or Direct Debit, and
  • the invoice's open amount is greater than 0.

Before executing the export, JustOn validates the SEPA payment information. The validation succeeds if the following conditions are true:

  • The invoice refers to a tenant.
  • The following fields of the tenant are set:

    SEPA Creditor ID

    IBAN

    Company

  • The following fields of the invoice are set:

    Bank Account

    Bank Account Owner

    Direct Debit Mandate Granted

    Direct Debit Mandate Reference

    Direct Debit Sequence Type

  • When using a CBI export format, the Member ID field of the tenant contains the ABI code of the bank.

Info

JustOn checks the format and structure (length, allowed characters, etc.) of the SEPA Creditor ID, IBAN, BIC and Direct Debit Mandate Reference according to the definitions in the SEPA Direct Debit Core Schemes.

The result of the validation is written to the SEPA Validation Error field. The bank transfer order for an invoice is exported if the SEPA Validation Error field is empty.

Configuring SEPA Direct Debit Export

SEPA Credit

JustOn exports SEPA Credit orders for invoices if

  • the payment method is either Bank Transfer or Direct Debit, and
  • the invoice's open amount is less than 0.

Before executing the export, JustOn validates the SEPA payment information. The validation succeeds if the following conditions are true:

  • The invoice refers to a tenant.
  • The following fields of the tenant are set:

    IBAN

    Company

  • The following fields of the invoice are set:

    Bank Account

    Bank Account Owner

  • When using a CBI export format, the Member ID field of the tenant contains the ABI code of the bank.

  • If Credit IBAN and Credit BIC are set for the tenant, JustOn uses these values instead of IBAN and BIC.

Info

JustOn checks the format and structure (length, allowed characters, etc.) of the IBAN and BIC according to the definitions in the SEPA Credit Transfer Schemes.

The result of the validation is written to the SEPA Validation Error field. The bank transfer order for an invoice is exported if the SEPA Validation Error field is empty.

Configuring SEPA Credit Export

DATEV Support

Basically, there are two ways to deliver invoice-related data to DATEV:

  • Transferring invoices and booking details as created from invoice line items to DATEV Unternehmen online
  • Exporting specifically formatted CSV files to be imported in a specific DATEV application

To seamlessly transfer invoice-based bookkeeping data to DATEV, JustOn integrates with JustOn Connector for DATEV. This is an add-on to JustOn that generates DATEV-specific data records from invoices and booking details as created from invoice line items, and transfers them to DATEV Unternehmen online. Once there, these accounting documents and accounting document items can be used to any DATEV application that accesses the DATEV Cloud.

DATEV.png
Directly transferring bookkeeping data to DATEV

In order to support specific DATEV applications (like, for example, DATEV Mittelstand Faktura mit Rechnungswesen or Kanzlei-Rechnungswesen), JustOn can export invoices and booking details (as created from both invoice line items and payment balances). It writes specifically formatted CSV files, which you can then import in the corresponding applications.

DATEV_CSV.png
Exporting CSV to be imported by DATEV applications

Data Transfer to DATEV

Your organization's business may require to transfer bookkeeping data to DATEV. To support this scenario, JustOn integrates with JustOn Connector for DATEV, an add-on to JustOn for transferring accounting documents to DATEV.

Note

The bookkeeping data transfer requires JustOn Connector for DATEV to be set up. For details, see JustOn Connector for DATEV DE.

In broad strokes, the bookkeeping data transfer work as follows:

JustOn transfers all booking details of a specific booking period that are not yet exported to JustOn Connector for DATEV. For each related invoice, an accounting document record of the type Accounts Receivable Ledger is created. Each booking detail is exported to an accounting document item (1:1 relationship). The two objects are linked with each other. Invoice PDF attachments are copied and attached to the accounting document.

On successful transfer, the Locked checkbox of the accounting document is selected, and the booking detail is marked as exported. In case of errors, neither an accounting document nor an accounting detail is created for the affected booking details. An error message is written to the booking detail.

Info

The bookkeeping data transfer to DATEV involves booking details created from invoice line items, since the corresponding DATEV interface supports invoice and cashbook data only. To transfer bookkeeping data as generated from payment balances to DATEV, you use a corresponding CSV file export.

The bookkeeping data transfer writes the data to the following fields.

Accounting Document fields
Field Data Type Source Field Notes
InvoiceId Text BookingDetail.InvoiceNo
Document Date Date BookingDetail.BookingPeriod Shows the start date of the booking period
Customer Name Text BookingDetail.AccountName
Customer City Text BookingDetail.BillingCity
IBAN Text BookingDetail.IBAN
SwiftCode Text BookingDetail.BIC
VatId Text BookingDetail.VATId
ThirdParty Checkbox - Is selected on successful transfer
Locked Checkbox - Is selected on successful transfer
ON_Invoice Lookup (Invoice) BookingDetail.Invoice Links to the related invoice
Accounting Document Item fields
Field Data Type Source Field Notes
Amount Currency (10,2) BookingDetail.Amount
AccountNo Text BookingDetail.AccountNo
Accounting Date Date BookingDetail.BookingDate
Tax Percent (2,2) BookingDetail.TaxRate
ON_BookingDetail Lookup (Booking Detail) - Links to the related (source) booking detail
Booking Detail fields
Field Data Type Notes
Exported Checkbox Is selected on successful transfer
Export Destination Text Is set to DATEV on successful export
ON_AccountingDetail Lookup (Accounting Document Item) Links to the related (target) accounting document item
Last Error Text Is set during the transfer
Additional fields

JustOn can copy additional fields from the booking details to the accounting documents and accounting document items. This is done for all additional fields on the booking detail if a field with the same name exists on the corresponding target.

Examples:

Booking Detail Field Accounting Document Field Accounting Document Item Field Result
BillingCountry__c BillingCountry__c n/a copy from booking detail to accounting document
Discount__c n/a Discount__c copy from booking detail to accounting document item
Duplicate__c Duplicate__c Duplicate__c copy from booking detail to accounting document and accounting document item

Enabling Data Transfer to DATEV

CSV Export

Your organization's business may require to export invoices or booking details that are to be imported by external accounting or ERP systems like DATEV or SAP. Usually, these accounting systems expect specifically formatted CSV files in order to import this data, including invoice line items and tax information. To this end, JustOn provides a flexible CSV export mechanism. It allows you to configure and execute invoice or booking details exports according to your needs.

In order to generate a CSV export that is compliant to the DATEV CSV format for the posting batch (Buchungsstapel), you must

JSON export configuration for DATEV CSV

To produce a DATEV posting batch-compliant CSV file, you can use the following JSON export configuration.

{
    "rows": {
        "bookingDetailRow": [
            "AbsAmount__c",
            "DebitCreditMark__c",
            "",
            "",
            "",
            "",
            "AccountNo__c",
            "OffsettingAccountNo__c",
            "TaxKey__c",
            "BookingDate__c",
            "InvoiceNo__c",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            ""
        ],
        "headerRow1": [
            "EXTF",
            "510",
            "21",
            "Buchungsstapel",
            "7",
            "TimeStamp",
            "",
            "SV",
            "Admin",
            "",
            "tenant.ClientNumber__c",
            "63021",
            "FiscalYearStart__c",
            "4",
            "StartDate",
            "EndDate",
            "Rechnungen",
            "",
            "1",
            "0",
            "0",
            "EUR",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "JustOn"
        ],
        "headerRow2": [
            "Umsatz (ohne Soll/Haben-Kz)",
            "Soll/Haben-Kennzeichen",
            "WKZ Umsatz",
            "Kurs",
            "Basis-Umsatz",
            "WKZ Basis-Umsatz",
            "Konto",
            "Gegenkonto (ohne BU-Schlüssel)",
            "BU-Schlüssel",
            "Belegdatum",
            "Belegfeld 1",
            "Belegfeld 2",
            "Skonto",
            "Buchungstext",
            "Postensperre",
            "Diverse Adressnummer",
            "Geschäftspartnerbank",
            "Sachverhalt",
            "Zinssperre",
            "Beleglink",
            "Beleginfo - Art 1",
            "Beleginfo - Inhalt 1",
            "Beleginfo - Art 2",
            "Beleginfo - Inhalt 2",
            "Beleginfo - Art 3",
            "Beleginfo - Inhalt 3",
            "Beleginfo - Art 4",
            "Beleginfo - Inhalt 4",
            "Beleginfo - Art 5",
            "Beleginfo - Inhalt 5",
            "Beleginfo - Art 6",
            "Beleginfo - Inhalt 6",
            "Beleginfo - Art 7",
            "Beleginfo - Inhalt 7",
            "Beleginfo - Art 8",
            "Beleginfo - Inhalt 8",
            "KOST1 - Kostenstelle",
            "KOST2 - Kostenstelle",
            "Kost-Menge",
            "EU-Land u. UStID",
            "EU-Steuersatz",
            "Abw. Versteuerungsart",
            "Sachverhalt L+L",
            "Funktionsergänzung L+L",
            "BU 49 Hauptfunktionstyp",
            "BU 49 Hauptfunktionsnummer",
            "BU 49 Funktionsergänzung",
            "Zusatzinformation - Art 1",
            "Zusatzinformation- Inhalt 1",
            "Zusatzinformation - Art 2",
            "Zusatzinformation- Inhalt 2",
            "Zusatzinformation - Art 3",
            "Zusatzinformation- Inhalt 3",
            "Zusatzinformation - Art 4",
            "Zusatzinformation- Inhalt 4",
            "Zusatzinformation - Art 5",
            "Zusatzinformation- Inhalt 5",
            "Zusatzinformation - Art 6",
            "Zusatzinformation- Inhalt 6",
            "Zusatzinformation - Art 7",
            "Zusatzinformation- Inhalt 7",
            "Zusatzinformation - Art 8",
            "Zusatzinformation- Inhalt 8",
            "Zusatzinformation - Art 9",
            "Zusatzinformation- Inhalt 9",
            "Zusatzinformation - Art 10",
            "Zusatzinformation- Inhalt 10",
            "Zusatzinformation - Art 11",
            "Zusatzinformation- Inhalt 11",
            "Zusatzinformation - Art 12",
            "Zusatzinformation- Inhalt 12",
            "Zusatzinformation - Art 13",
            "Zusatzinformation- Inhalt 13",
            "Zusatzinformation - Art 14",
            "Zusatzinformation- Inhalt 14",
            "Zusatzinformation - Art 15",
            "Zusatzinformation- Inhalt 15",
            "Zusatzinformation - Art 16",
            "Zusatzinformation- Inhalt 16",
            "Zusatzinformation - Art 17",
            "Zusatzinformation- Inhalt 17",
            "Zusatzinformation - Art 18",
            "Zusatzinformation- Inhalt 18",
            "Zusatzinformation - Art 19",
            "Zusatzinformation- Inhalt 19",
            "Zusatzinformation - Art 20",
            "Zusatzinformation- Inhalt 20",
            "Stück",
            "Gewicht",
            "Zahlweise",
            "Forderungsart",
            "Veranlagungsjahr",
            "Zugeordnete Fälligkeit",
            "Skontotyp",
            "Auftragsnummer",
            "Buchungstyp",
            "Ust-Schlüssel (Anzahlungen)",
            "EU-Land (Anzahlungen)",
            "Sachverhalt L+L (Anzahlungen)",
            "EU-Steuersatz (Anzahlungen)",
            "Erlöskonto (Anzahlungen)",
            "Herkunft-Kz",
            "Leerfeld",
            "KOST-Datum",
            "Mandatsreferenz",
            "Skontosperre",
            "Gesellschaftername",
            "Beteiligtennummer",
            "Identifikationsnummer",
            "Zeichnernummer",
            "Postensperre bis",
            "Bezeichnung SoBil-Sachverhalt",
            "Kennzeichen SoBil-Buchung",
            "Festschreibung",
            "Leistungsdatum",
            "Datum Zuord.Steuerperiode"
        ]
    },
    "rowOrder": [
        "headerRow1",
        "headerRow2",
        "bookingDetailRow"
    ],
    "columns": {
        "headerRow1": {
            "index": {
                "1": {
                    "forceQuotes": true
                },
                "4": {
                    "forceQuotes": true
                },
                "8": {
                    "forceQuotes": true
                },
                "9": {
                    "forceQuotes": true
                },
                "17": {
                    "forceQuotes": true
                },
                "18": {
                    "forceQuotes": true
                },
                "22": {
                    "forceQuotes": true
                },
                "24": {
                    "forceQuotes": true
                },
                "27": {
                    "forceQuotes": true
                },
                "30": {
                    "forceQuotes": true
                },
                "31": {
                    "forceQuotes": true
                }
            }
        },
        "bookingDetailRow": {
            "index": {
                "1": {},
                "2": {
                    "forceQuotes": true
                },
                "3": {
                    "forceQuotes": true
                },
                "4": {},
                "5": {},
                "6": {
                    "forceQuotes": true
                },
                "7": {},
                "8": {},
                "9": {
                    "forceQuotes": true
                },
                "10": {
                    "options": {
                        "dateFormat": "ddMM"
                    }
                },
                "11": {
                    "forceQuotes": true
                },
                "12": {
                    "forceQuotes": true
                },
                "13": {},
                "14": {
                    "forceQuotes": true
                },
                "15": {},
                "16": {
                    "forceQuotes": true
                },
                "17": {},
                "18": {},
                "19": {},
                "20": {
                    "forceQuotes": true
                },
                "21": {
                    "forceQuotes": true
                },
                "22": {
                    "forceQuotes": true
                },
                "23": {
                    "forceQuotes": true
                },
                "24": {
                    "forceQuotes": true
                },
                "25": {
                    "forceQuotes": true
                },
                "26": {
                    "forceQuotes": true
                },
                "27": {
                    "forceQuotes": true
                },
                "28": {
                    "forceQuotes": true
                },
                "29": {
                    "forceQuotes": true
                },
                "30": {
                    "forceQuotes": true
                },
                "31": {
                    "forceQuotes": true
                },
                "32": {
                    "forceQuotes": true
                },
                "33": {
                    "forceQuotes": true
                },
                "34": {
                    "forceQuotes": true
                },
                "35": {
                    "forceQuotes": true
                },
                "36": {
                    "forceQuotes": true
                },
                "37": {
                    "forceQuotes": true
                },
                "38": {
                    "forceQuotes": true
                },
                "39": {},
                "40": {
                    "forceQuotes": true
                },
                "41": {},
                "42": {
                    "forceQuotes": true
                },
                "43": {},
                "44": {},
                "45": {},
                "46": {},
                "47": {},
                "48": {
                    "forceQuotes": true
                },
                "49": {
                    "forceQuotes": true
                },
                "50": {
                    "forceQuotes": true
                },
                "51": {
                    "forceQuotes": true
                },
                "52": {
                    "forceQuotes": true
                },
                "53": {
                    "forceQuotes": true
                },
                "54": {
                    "forceQuotes": true
                },
                "55": {
                    "forceQuotes": true
                },
                "56": {
                    "forceQuotes": true
                },
                "57": {
                    "forceQuotes": true
                },
                "58": {
                    "forceQuotes": true
                },
                "59": {
                    "forceQuotes": true
                },
                "60": {
                    "forceQuotes": true
                },
                "61": {
                    "forceQuotes": true
                },
                "62": {
                    "forceQuotes": true
                },
                "63": {
                    "forceQuotes": true
                },
                "64": {
                    "forceQuotes": true
                },
                "65": {
                    "forceQuotes": true
                },
                "66": {
                    "forceQuotes": true
                },
                "67": {
                    "forceQuotes": true
                },
                "68": {
                    "forceQuotes": true
                },
                "69": {
                    "forceQuotes": true
                },
                "70": {
                    "forceQuotes": true
                },
                "71": {
                    "forceQuotes": true
                },
                "72": {
                    "forceQuotes": true
                },
                "73": {
                    "forceQuotes": true
                },
                "74": {
                    "forceQuotes": true
                },
                "75": {
                    "forceQuotes": true
                },
                "76": {
                    "forceQuotes": true
                },
                "77": {
                    "forceQuotes": true
                },
                "78": {
                    "forceQuotes": true
                },
                "79": {
                    "forceQuotes": true
                },
                "80": {
                    "forceQuotes": true
                },
                "81": {
                    "forceQuotes": true
                },
                "82": {
                    "forceQuotes": true
                },
                "83": {
                    "forceQuotes": true
                },
                "84": {
                    "forceQuotes": true
                },
                "85": {
                    "forceQuotes": true
                },
                "86": {
                    "forceQuotes": true
                },
                "87": {
                    "forceQuotes": true
                },
                "88": {},
                "89": {},
                "90": {},
                "91": {
                    "forceQuotes": true
                },
                "92": {},
                "93": {},
                "94": {},
                "95": {
                    "forceQuotes": true
                },
                "96": {
                    "forceQuotes": true
                },
                "97": {},
                "98": {
                    "forceQuotes": true
                },
                "99": {},
                "100": {},
                "101": {},
                "102": {
                    "forceQuotes": true
                },
                "103": {
                    "forceQuotes": true
                },
                "104": {},
                "105": {
                    "forceQuotes": true
                },
                "106": {},
                "107": {
                    "forceQuotes": true
                },
                "108": {},
                "109": {
                    "forceQuotes": true
                },
                "110": {
                    "forceQuotes": true
                },
                "111": {},
                "112": {
                    "forceQuotes": true
                },
                "113": {},
                "114": {},
                "115": {},
                "116": {}
            }
        }
    },
    "decimalPlaces": {},
    "markAsExported": false,
    "columnSeparator": ";",
    "useASCII": true,
    "filterLineBreaks": true,
    "useCRLF": true,
    "fileName": "EXTF_Buchungsstapel_[StartDate]_[EndDate].csv",
    "options": {
        "decimalSeparator": ",",
        "groupingSeparator": "",
        "dateFormat": "yyyyMMdd",
        "timeFormat": "yyyyMMddHHmmssSSS",
        "language": "de"
    }
}
Required custom fields

The JSON example configuration requires additional custom fields:

Object Field Description
Tenant ClientNumber__c The client number (Mandantennummer) for this tenant.
Booking Period FiscalYearStart__c The start of the fiscal year (Wirtschaftsjahresbeginn).
Booking Detail AbsAmount__c The absolute amount of this booking detail (must be greater than 0).
Booking Detail OffsettingAccountNo__c The offsetting account (Gegenkonto, required value).
Booking Detail DebitCreditMark__c Defined by the revenue amount and related to the account number.
Booking Detail TaxKey__c The tax key (Steuerschlüssel).

Configuring Booking Detail CSV Export