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:

Finally, you usually transfer your invoicing data to your accounting system, irrespective of the features you use.

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.

Detail Levels

With respect to the accounting support, JustOn distinguishes four virtual "complexity" 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.

Best Practice: Generating Bookkeeping Data

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 finleap connect 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, Write-off, Dunning Fee 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.

Data Transfer to Accounting Systems

Irrespective of the bookkeeping data generation features you apply, your organization usually delivers the relevant invoicing data to an (external) accounting system like DATEV, SAP or Microsoft Dynamics. Invoicing data refers to the actual business transactions that state the realized revenues or charged taxes and their corresponding booking accounts, as represented in booking details. Accounting systems expect specifically formatted CSV files in order to import this data. To support this, JustOn provides a flexible CSV export mechanism, which allows you to configure and execute booking details exports according to your needs.

Info

If your target accounting system is DATEV, you may consider using DATEV Unternehmen online. JustOn supports the automatic transfer of invoicing data to this platform.

In addition, your business may require to export master data to your accounting system. Master data refers to account-related data like customer name, address, tax ID, debtor/creditor number, etc. Accounting systems usually handle master data separately and can therefore not import it together with invoicing data. For transferring master data, you use JustOn's export mechanism to produce specifically configured CSV files from invoices.

accounting_data_transfer
Delivering bookkeeping data to accounting systems

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.
Write-Off Is created for an invoice on write-off.
IVA Is created for an invoice when applying an individual value adjustment.

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 for automatically registering pre-payments, see Using Pre-Payment Data on Invoices.

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 balance is not locked as a result of a refund
  • 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.

If an invoice has set a balance assignment key, JustOn assigns balances only if they have set the same key or if their key fields are empty.

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.

For details on manual balance assignment, see Manually Controlling Assignments.

Pre-Payment Balance

Your business model may involve pre-payments – payments for some product or service, executed before the corresponding invoice is created. On invoice generation, however, you must take into account these pre-payments and, accordingly, reduce the open invoice amount.

JustOn supports two ways for automatically dealing with pre-payments. Which to use depends on the type of products you sell and the corresponding billing model:

  • For one-time products, you can have the pre-payment data directly added to the invoices. On finalization, JustOn creates specific prepaid balances, which reduce the payment amount or settle the invoices immediately.

    For details, see Using Pre-Payment Data on Invoices

  • For repeated billing, you can have a pre-payment balance automatically assigned to an invoice. This reduces the payment amount or, if balanced out completely, sets the invoice Paid.

    For details, see Assigning Pre-Payment Balance to Invoice

Using Pre-Payment Data on Invoices

JustOn can generate balance records of the type Prepaid based on specific pre-payment data on invoices.

JustOn automatically creates a prepaid balance for pre-payments when an invoice that contains specific pre-payment data is finalized. If the pre-payment covers the open invoice amount, the invoice immediately becomes Paid.

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

Assigning Pre-Payment Balance to Invoice

For repeated billing based on recurring items or automatic subscription renewal, you can have a balance of the type Prepayment assigned to the first invoice of the expected series. JustOn makes use of a specific balance assignment key to make sure that the automatic balance assignment correctly relates the balances with the matching invoices. To hold the key, JustOn 2.66 has introduced the field Balance Assignment Key on the Subscription, Invoice and Balance objects.

In broad outline, the feature works as follows:

(1) You use an external system that handles orders and payments. Based on this information, the external system prepares the source data for both JustOn's invoice creation and balance assignment, making sure that the balance assignment key is correctly set.

Info

The source data preparation and provision is project-specific, as it depends on your business data and system environment. Be aware that providing for the required source data may involve some implementation effort.

(2) JustOn retrieves the invoicing data, including the balance assignment key, either as source data for automatically building subscriptions or for the generic invoice run. To support the balance assignment key with the subscription build or the generic invoice run, you must create the field ON_BalanceAssignmentKey on the corresponding source object and then make sure to have it set on the relevant source records. Subsequently,

  • when building subscriptions, the balance assignment key is set on the produced subscriptions, from where it is copied to the invoices on invoice generation,
  • with the generic invoice run, the balance assignment key is immediately set on the produced invoices.

(3) JustOn retrieves the pre-payment data, creating balance records of the type Prepayment, which also include the balance assignment key.

(4) On invoice finalization, JustOn applies the automatic balance assignment, relating the available pre-payment balances with the corresponding invoices

  • if the balance assignment keys on the invoice and the balance match, or
  • if the balance assignment key on the invoice is set and the key field on the balance is empty.

Once the source data is set up and prepared accordingly, JustOn automatically assigns the available pre-payment balances to the corresponding invoices. No further configuration is necessary.

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 write off certain invoice amounts:

  • If an assigned payment does not exactly match the invoice amount, you can write off the missing amount. Differences to cover may, for example, result from currency conversions upon payment matching. You define the difference that you are ready to accept and offset consequently according to your business requirements. In order to enable the automatic balance write-off after payment, you specify either a (percentage) threshold or an absolute amount in the global settings.
  • If your business model allows it, you can write off the complete invoice immediately upon finalization. This may be sensible for invoices with small amounts, which you may consider not worth collecting. To enable the automatic, immediate invoice write-off, you specify an absolute amount in the global settings. The date of the write-off balance will be set to the date of the invoice finalization.
  • You can write off an invoice manually. Doing so creates a balance of the type Write off, which is immediately assigned to the current invoice. By default, JustOn sets the current open amount of the invoice as the balance amount. You can, however, modify this value.

Once applied accordingly, JustOn reduces the open invoice amount or, if offset completely, sets the invoice status to Paid and the invoice balance to 0.

For tracking purposes, the balance write off records a reason in the field Write-Off Reason. The following values are available by default:

Value Description
Missing amount below threshold Set when automatically creating write-off balance on payment registration.
Invoice below threshold Set when automatically creating a write-off balance on invoice finalization.
Manual write-off Default value when manually creating a write-off balance.

Info

The write-off reason is included by the creation of booking data from balances and can be used to configure the Collective Accounts.

If required by your business, you can modify the reasons for the (manual) balance write-off.

The following global settings control the behavior of the automatic write off:

Field Type Description
Write-Off Threshold Percent (13,5) Defines a percentage for the threshold that triggers the automatic creation of a write-off balance when a payment is registered.
Write-Off Cap Amount Number (13,5) Defines an amount for the threshold that triggers the automatic creation of a write-off balance when a payment is registered.
Finalization Write-Off Amount Number (13,5) Defines an amount for the threshold that triggers the automatic creation of a write-off balance when an invoice is finalized.
Write-Off Currency Text (3) Specifies the ISO code of the currency to be used for a threshold amount.

Info

For creating write-off balances after payment, you can combine the percentage and the absolute amount. In this case, JustOn limits the calculated threshold to the specified amount.

Creating write-off balances on finalization supports absolute amounts only.

Automatic write-off examples

Creating a write-off balance when receiving a payment:

(1) There is an invoice (and an according balance record) of 119,00.

(2) The customer pays in a different currency, and after converting the payment amount, JustOn registers a payment balance record of -118,00.

(3) 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. The write-off reason is set to Missing amount below threshold

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

Creating a write-off balance on finalization:

(1) There is an invoice (and an according balance record) of 1,50.

(2) With a finalization write-off amount set to 2, JustOn automatically creates a write-off balance record of -1,50 when the invoice is finalized, which clears the complete amount immediately. The write-off reason is set to Invoice below threshold

# Balance Type Amount
1 Invoice 1,50
2 Write-off -1,50

Be aware of the some specifics when payment balances come into play in these contexts:

  • Invoice below threshold

    If there is already a payment balance assigned to an invoice on finalization, like a pre-payment or a deposit invoice payment, JustOn applies the workflow for creating a write-off balance upon registering a payment, irrespective of any finalization write-off settings.

  • Missing amount below threshold

    When registering a payment, the write-off amount is adjusted according to the new total payment amount.

  • Manual write-off

    When registering a payment, manual write-off balances are removed if necessary to avoid overpayment. Write-off balances with the same write-off reason are removed together, beginning with the latest manual write-off.

Existing write-off balances are never deleted or modified. If the write-off has to be adjusted, JustOn creates reverse write-off balances and, if required, a new write-off balance with the modified amount.

Enabling Automatic Balance Write-Off
Manually Writing Off Invoices

Individual Value Adjustment

Outstanding payments may become doubtful debts or bad debts. That is, they may turn out unlikely to be collected. In such cases, you usually devalue the corresponding invoice amounts, allowing a reduction of your accounts receivable.

JustOn supports the individual value adjustment based on accordingly configured dunning levels. That is, you can devalue invoice (net) amounts by a defined percentage rate when the relevant dunning level is reached.

Enabling Individual Value Adjustment

IVA Balance

JustOn implements individual value adjustments with balances of the type IVA that count against the invoice balance. The IVA balance amount is calculated based on the invoice net amount:

(invoice total net - payment net) * IVA rate

So if you increase the IVA percentage to a 100%, the invoice tax amount will remain due, leaving the invoice in the status Open.

The payment net amount is calculated from the sum of all payment balances using the unique tax rate of the invoice. This requires that the same tax rate is used for all invoice line items of the related invoice (except for information invoice line items and line items without tax). So be aware that finalizing a dunning with an applied IVA will fail if there is no unique invoice tax rate.

A manual write-off is handled like a payment.

IVA Workflow

JustOn automatically creates IVA balances when an accordingly configured dunning level is applied. To this end, you specify the IVA percentage of the invoice (net) amount that you want to apply in the relevant dunning level. JustOn takes existing payments and manual write-off balances into account when generating IVA balances.

You can configure dunning levels with an increasing IVA percentage. If the next dunning level is reached, JustOn reverses the existing IVA balance and creates a new IVA balance.

The IVA Percentage is written to the field IVA Percentage of the invoice when the dunning is finalized.

The IVA balance amount of an invoice is automatically adjusted in the following cases:

  • Registering, unregistering or deleting a payment
  • Modifying a manual write-off
  • Finalizing a dunning with another IVA percentage

The individual value adjustment is usually a preliminary step to a complete write-off. That is, when the IVA percentage has reached a 100%, you will most probably proceed to manually writing off the invoice.

IVA Balance Examples

Example: Registering payment on invoice with IVA balances

The Register Payment operation ignores IVA balances. The default payment amount is set as if there was no IVA balance.

Assume the following invoice:

Grand Total Tax Rate Total Net
1160 16 1000

First dunning with a 30% IVA percentage:

IVA Percentage IVA Amount Description
30 -300 Total Net * 30% = 1000 * 0.3 = 300

Second dunning with a 50% IVA percentage reverses the first IVA balance and creates a new one:

IVA Percentage IVA Amount Description
50 -300 Initial IVA
+300 Reverse IVA
-500 Total Net * 50% = 1000 * 0.5 = 500

Registering a payment adjusts the IVA amount to the current invoice IVA percentage:

Payment (gross) Payment (net) IVA Percentage IVA Amount Description
50 -300 Initial IVA
+300 Reverse initial IVA
-500 Previous IVA
290 250 +500 Reverse previous IVA
-375 (Total Net - Payment Net) * 50% = (1000 - 250) / 2 = 375
Example: Manual write-off

Manually writing off ignores IVA balances. The default write-off amount is set as if there was no IVA balance. JustOn's Invoice Write-Off page, however, shows the current IVA amount for information purposes if the IVA percentage is set on the invoice.

Usually, you completely write off an invoice with a 100% IVA percentage. This will reverse the IVA balance and create a write-off balance for the complete invoice amount, setting the invoice status to Paid.

Write-Off Amount IVA Percentage IVA Amount Description Invoice Status
50 -500 Initial IVA Open
100 +500 Reverse IVA Open
-1000 100% IVA Open
1160 +1000 Reverse IVA Paid

Payment Balance Refund

Using the payment page shipped with the JustOn Self-Service Extension, businesses can provide their customers the option to directly pay their invoices. To this end, the JustOn Self-Service Extension can integrate with payment service providers.

Depending on your payment service provider integration, you can use JustOn's balance management functionality to directly refund a payment made via the payment page of the JustOn Self-Service Extension.

Info

As of JustOn 2.60 and JustOn Self-Service 1.44, the payment refund is available with the Stripe 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.

Credit and Refund Workflows

The following sections illustrate likely business use cases that combine credit creation with payment refunds. The examples outline the involved steps and show their key results.

Refunding a payment without creating a credit

(1) Finalize invoice

(2) Register payment

(3) Refund payment

refund_uc1
Refunding a registered payment

For additional examples of complete or partial refunds, see Refund Handling Examples.

Refunding a payment with a credit issued before payment receipt

(1) Finalize invoice

(2) Create (partial) credit

(3) Register payment

(4) Refund payment

refund_uc1a
Refunding a registered payment for a partially cleared (reduced) invoice amount

Refunding a payment with a credit issued after payment receipt

(1) Finalize invoice

(2) Register payment

(3) Create (partial) credit

(4) Refund credited amount

(5) Finalize credit

(6) Manually settle open credit with refund balance

refund_uc2
Refunding a registered payment after creating a (partial) credit

Refunding a payment with a credit issued after refund

(1) Finalize invoice

(2) Register payment

(3) (Partially) refund payment

(4) Create (partial) credit

(5) Finalize credit

  • Individually from the detail view: Requires manual settlement with the refund balance using the function Register Payment
  • Via batch process from the list view: JustOn automatically assigns the refund balance upon finalization

refund_uc3
Refunding a registered payment before creating a (partial) credit

Refund Handling Examples

The following section summarizes some examples for the successful refund handling, illustrating its behavior.

Completely refund a single payment

Payment balances

Amount Selected for Refund
-100,00

Resulting refund and payment balances

Type Amount Locked
Payment -100,00
Refund 100,00
Partially refund a single payment

Payment balances

Amount Selected for Refund
-100,00

Resulting refund and payment balances after refunding the amount of 25,00:

Type Amount Locked
Payment -75,00
Payment -25,00
Refund 25,00
Completely refund a split payment

Payment balances

Amount Selected for Refund
-75,00
-25,00

Resulting refund and payment balances after refunding the amount of 25,00;

Type Amount Locked
Payment -75,00
Payment -25,00
Refund 25,00
Partially refund a split payment

Payment balances

Amount Selected for Refund
-75,00
-25,00

Resulting refund and payment balances after refunding the amount of 40,00;

Type Amount Locked
Payment -60,00
Payment -15,00
Payment -25,00
Refund 25,00
Refund 15,00
Refund amount is larger than original payment amount

Payment balances

Amount Selected for Refund
-75,00

Resulting refund and payment balances after refunding the amount of 100,00;

Type Amount Locked
Payment -75,00
Payment -25,00
Refund 75,00
Refund 25,00

Implementation Details
Enabling Payment Refund
Stripe Refund Handling
Refunding Payment

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, which, consequently, creates corresponding balance records. Each payment entry represents a record of a bank statement, that is, a registered payment operation intended to meet an open invoice amount.

There are two ways to acquire payment entries:

  • importing bank statements from CSV files or
  • retrieving banking transactions from finleap connect.

Info

Using an integration with an external payment provider, like PayPal or Stripe, JustOn directly creates payment balance records for the captured amount.

In addition, you can manually set an invoice Paid using the function Register Payment, which also directly creates a payment balance record.

Payment Entry Matching and Assignment

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

(1) 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.

JustOn compares the contents of the payment reference with specified fields of the matching target objects. If a matching invoice number is found, it always takes precedence over other possible matches. For further details, see Matching Logic.

(2) 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.

If there is no matching invoice or dunning but a matching account, a payment entry can be assigned to the corresponding account. This creates a balance record on the account. Doing so, you can, for example, handle pre-payments received from customers before the invoices are issued.

Info

Be aware of the following payment matching specifics:

  • For the matching to work, the payment entry field Payment Provider must be either empty or set to figo.
  • 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 sorts them by their date and settles the oldest one first.
  • For payment entries assigned to statements (dunnings or account statements), JustOn distributes the payment amount to the invoices referred to by the statement. Again, the invoices are sorted by their date, with the oldest one 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, the IBAN and the account number:

Name Source Field Reference Match Expression
Invoice Number Invoice__c Name
Invoice IBAN Invoice__c BankAccount__c [A-Z]{2,2}[0-9]{2,2}[a-zA-Z0-9]{1,30}
Account Number Invoice__c Account__r.AccountNumber

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.

Info

JustOn compares the payment reference with all specified fields. A matching invoice number, however, always takes precedence over other possible matches.

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

finleap connect Integration

JustOn integrates with finleap connect 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 "finleap connect 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 finleap connect
Managing finleap connect Banking Transactions

finleap connect Filters

To filter the transactions to be retrieved, you specify finleap connect filters.

  • finleap connect Transaction Filters control which types of banking transactions are to be transferred.
  • finleap connect 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.

finleap connect Filters

finleap connect Data Conversion

finleap connect 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 finleap connect transaction
TransactionNo__c <transaction_id> Internal finleap connect 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 finleap connect account ID
BookingDate__c <booking_date> Booking date
ProviderSpecificData__c complete transaction JSON data The retrieved finleap connect transaction JSON data for this object

The JSON data of the figo Connect Transaction object 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 finleap connect 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 finleap connect transaction
TransactionNo__c <transaction_id> Internal finleap connect 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 or bank account data and use it to automatically collect payments for open invoices.

Info

For credit card-based payments, 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.

General payment workflow

Assume a merchant's org that integrates the JustOn Self-Service Extension with a payment service provider. The payment page is set up to provide invoice recipients (as payment guest users) the option to pay their invoices.

payment_process
General payment workflow

(1) The invoice recipient (as payment guest user) clicks Pay Now for one of the available payment providers.

  • This displays an input form that allows to enter the banking details.
  • The user clicks the pay button on the input form.

(2) Upon receiving the payment request, the payment provider validates the data.

(3) On successful validation, the payment provider captures the payment amount in the user's bank. Otherwise, the payment provider returns an error, which is displayed in the input form.

(4) The payment provider notifies JustOn about the capture result.

  • If the capture is successful, JustOn creates a Balance record for the captured amount, and displays the success message. The balance field TransactionNo is set to a provider-specific transaction number for this capture.
  • If the capture is not successful, JustOn creates a Payment Entry record that holds the provider-specific information about the failed capture, and displays an error message.

(5) On the next settlement date, the user's bank transfers the captured amount to the payment provider. Subsequently, the payment provider passes the amount to the merchant's bank.

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 automatic payment collection usually 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. JustOn saves the card data in an account-specific payment instrument.
  • 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 using the stored payment instrument, creates a corresponding balance and sets the invoice Paid.

    Postponing the payment due date for an invoice suspends applicable payment collections for the specified time.

Note

Be aware that by default, there is no option for your users to disable the automatic payment collection after they have opted to use future payments. If required or on your user's request, you deactivate individual payment instruments manually (see How to disable payment instruments?). Make sure to establish according business processes.

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 finalization batch process. 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).

Be aware of the following specifics:

  • For an open invoice or credit to be considered for settlement, its due date must be reached.
  • If you work with business entities, the business entity specified for both the invoice and the credit must match for the settlement to take place.

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>

settlement
Settling an invoice against a credit

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 statement 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. Statement details are in a master-detail relationship to a statement.

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:

Invoice payment due
Failure to payment: First reminder
      Failure to first reminder: Second reminder
           Failure to second reminder: Final reminder

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

Postponing the payment due date for an invoice suspends applicable dunning procedures for the specified time.

Dunning procedure examples

Example dunning procedure using three dunning level configurations (First Reminder, Second Reminder, Final Reminder) with a fix dunning fee:

Dunning Characteristic First Reminder Second Reminder Final Reminder
friendly reminder about an outstanding payment firm reminder of the overdue amount, adding a late payment charge last request to pay before legal action is taken and the service is terminated
Grace Period 30 days 60 days 90 days
Dunning Fee 0,00 5,00 10,00

If you apply fix dunning fees, JustOn recommends to include the corresponding information in the statement detail table of templates for higher dunning levels.

Example dunning procedure using three dunning level configurations (First Reminder, Second Reminder, Final Reminder) with a percentage late fee:

Dunning Characteristic First Reminder Second Reminder Final Reminder
friendly reminder about an outstanding payment firm reminder of the overdue amount, adding a late payment charge last request to pay before legal action is taken and the service is terminated
Grace Period 30 days 60 days 90 days
Late Fee Rate 0% 2% 5%

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.

Bookkeeping data for dunning reminders

When finalizing a dunning, JustOn creates balances of the type Dunning Fee for the defined dunning fees and adds them to the account balance of the relevant account. You must, consequently, generate bookkeeping data from balances to produce dedicated dunning fee bookings. To set the intended account number, you need a collective account setting where Account specifies the required G/L account and Type is set to Dunning Fee.

JustOn will not create new booking details for the invoices that are subject to dunning processes. Bookkeeping data for invoices is produced on invoice finalization only.

howto_booking_dunning
Dunning-relevant booking details

Operation Dunning Records Relevant Step Accounting Records
Generating draft invoice Invoice
Invoice line items
Finalizing invoice          (1) Invoice booking details
Generating draft dunning Statement
Statement details
Finalizing dunning Dunning fee balances (2)
Creating balance booking details          (3) Balance booking details

Managing Dunning Reminders
Setting Up Dunning Process Management

Bookkeeping Data for Invoices

JustOn allows for writing bookkeeping data for revenues and taxes from finalized invoices. These records can then be transferred to accounting systems like DATEV, SAP or Microsoft Dynamics via CSV export or, for DATEV, direct transfer.

Once created, the booking details can no longer be modified or deleted.

Enabling Bookkeeping Data Generation
Best Practice: Generating Bookkeeping Data

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 business entities.

The following fields are available:

Field Data Type Possible Values Required Description
Name Text The booking period name, is set automatically using this pattern:
BUSINESS-ENTITY-YEAR-MONTH (w/ business entity)
YEAR-MONTH (w/o business entity)
Month Picklist 01, 02 ... 12 The month for the booking period.
Year Text (4) 2017 The year for the booking period.
Business Entity Text (255) The business entity 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
Absolute Amount Amount The absolute amount of the booking detail, to be used together with the debit/credit flag.
Account Invoice.Account The account for the booking detail.
Account Name Invoice.AccountName The account name as taken from the invoice.
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.
Balance The source balance for booking details of the type Payment.
Bank Account ID The internal bank account ID of the payment provider 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.
Billing Practice The billing practice of recurring items for booking details of the type Unbilled Revenue.
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.
Booking Text The booking reference text as defined by a corresponding Booking Text custom setting.
Business Entity BookingPeriod.Tenant The business entity of the related booking period.
Business Partner Account Number Account.ON_DebtorNo
CollectiveAccount.BpAccount
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.
Center InvoiceLineItem.Center The cost center or profit center for this booking detail.
Center Split Percentage The percentage of this booking detail with regard to the center split.
Credit Amount
AbsoluteAmount
Is set for booking details that represent credits (positive values).
Currency The currency for the booking detail.
Debit Amount
AbsoluteAmount
Is set for booking details that represent debits (negative values).
Debit/Credit Flag Amount Flags the absolute amount either as debit (S) or credit (H).
Export Destination The export target, is set automatically upon export.
Exported Selected automatically upon export completion.
G/L Account Number InvoiceLineItem.GLAccount The general ledger account as taken from the invoice line item.
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.
Is Gross Is set to true for booking details of the type Revenue if Enable Accounting in Gross Values is enabled (see Enabling Bookkeeping Data Generation) and the amount is inclusive of taxes.
Is Preliminary Is set to true for booking details of the type Unbilled Revenue.
Last Error Shows export errors, is set automatically upon export.
Original Booking Date Invoice.ON_BookingDate
Invoice.Date
The original booking date is derived from the invoice Date field or, if configured, from ON_BookingDate. The value is kept separately and, as opposed to the Booking Date field, remains unchanged (irrespective of booking period shifts or other modifications) to serve as input for certain booking approaches.
Payment Date The date of the original payment balance for booking details of the type Payment.
Payment Provider The payment provider for booking details of the type Payment.
Region The economic region, like EU, EMEA.
Split Origin Booking Detail The ID of the original booking detail of a center split.
Subscription The related subscription for booking details of the type Unbilled Revenue.
Tax Code InvoiceLineItem.TaxCode The tax code of the applied tax rule.
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.

Accountants may expect specific references to the operation from which produced booking details originate. To support this requirement, you can use booking texts. They define the content and pattern of this human-readable reference information, and JustOn then populates the Booking Detail field Booking Text accordingly.

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 canceled 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.
  • For the booking date of the new booking detail, JustOn sets the date of the canceled invoice as long as the original booking period is Open. If, however, the original booking period is Closed, JustOn uses the first day of the next open booking period.
  • For the booking text of the new booking detail, JustOn prepends Cancellation: to the original booking text.

    This text is a custom label. If you need a locale-specific variant, provide a corresponding translation as described in Managing Custom Labels.

Bookkeeping data for deposit invoices

As deposit invoices do usually not constitute a legally binding payment request, they are usually exempt from bookkeeping data generation. If your accounting processes, however, require to book deposit invoices as soon as they are created, you can explicitly enable the bookkeeping data generation for deposit invoices using the global setting Create Bookkeeping Data for Deposit.

Bookkeeping data for dunning reminders

When finalizing a dunning, JustOn creates balances of the type Dunning Fee for the defined dunning fees and adds them to the account balance of the relevant account. You must, consequently, generate bookkeeping data from balances to produce dedicated dunning fee bookings. To set the intended account number, you need a collective account setting where Account specifies the required G/L account and Type is set to Dunning Fee.

JustOn will not create new booking details for the invoices that are subject to dunning processes. Bookkeeping data for invoices is produced on invoice finalization only.

howto_booking_dunning
Dunning-relevant booking details

Operation Dunning Records Relevant Step Accounting Records
Generating draft invoice Invoice
Invoice line items
Finalizing invoice          (1) Invoice booking details
Generating draft dunning Statement
Statement details
Finalizing dunning Dunning fee balances (2)
Creating balance booking details          (3) Balance booking details

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 revenue recognition rule specified 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, if configured accordingly. 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 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.
Margin Scheme Creates three booking details per invoice line item if margin schemes apply: one for the defined margin, one for the position total minus the margin, and one for the tax on the margin. The tax rate for the margin is stored in the field Margin Tax Rate, while the field Tax Rate is set to 0.
The Margin Scheme recognition rule is available as of JustOn 2.68.

Applying Tax Recognition

JustOn supports tax recognition rules. They control the booking detail creation for taxes.

JustOn determines the tax recognition rule to be applied via the invoice line item field Tax 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 tax recognition rule specified automatically on the invoice line item when generating invoices.

The following tax recognition rules are available:

Tax Recognition Rule Description
Default Creates individual booking details for the taxes applied to an invoice line item. The booking date is taken from the invoice line item field ON_BookingDate, with the invoice date used as fallback.
If you use gross values when creating bookkeeping data, JustOn does not create tax booking details.
Sync With Revenue Creates an individual tax booking detail for each revenue booking detail that is created according to the applied revenue recognition rule. The booking date is taken from the revenue booking detail.
If you use gross values when creating bookkeeping data, JustOn does not create tax booking details, and the global setting Accounting Gross Taxes on First Month is ignored.

The example 4 below and the article How to model "permanent" invoices? illustrate the behavior.

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. By default, 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 Gross Value Bookings), JustOn does not create tax details.

Optionally, you can configure the booking detail creation for taxes by applying a tax recognition rule on the line item.

(2) Assigning Booking Details to Booking Periods

Each booking detail is assigned to a booking period, where the specified booking date determines 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.

JustOn supports custom booking dates. If not set, the invoice date is used as fallback.

(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

Combined Monthly revenue recognition rule with Sync With Revenue tax recognition rule

Some business use cases require both revenue and tax to be distributed across the service period on a monthly base. To this end, you combine the Monthly revenue recognition rule with the Sync With Revenue tax recognition rule.

This allows, for example, to cover larger service periods partially on a regular base. Assume an invoice with a service period of one year and one invoice line item:

G/L Account Recognition Rule Tax Recognition Rule Pos Total Net Pos Total Tax Tax Rate Invoice No.
0001 Monthly Sync With Revenue 60,00 11,40 19% R12345

Now combining the Monthly revenue recognition rule with the Sync With Revenue tax recognition rule produces 24 booking details:

# Type Account No. Amount Tax Rate Name
1,3,5..23 Revenue 0001 5,00 19% 0001-R12345
2,4,6..24 Tax 0,95 19% 19.0-R12345

Applying a staged payment plan (installments) to the invoice, you can, in addition, request synchronized payments.

booking_details_tax_monthly
Booking details split by revenue/tax with monthly revenue recognition and synchronized tax distribution

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. As of version 2.52, JustOn supports deferred revenue handling.

Info

Staged payment plans (installments) do not imply revenue deferral. If not specifically set otherwise, JustOn consequently applies the Default revenue recognition rule when generating bookkeeping data for invoices with installments.

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.

Info

By default, JustOn fills the field Business Partner Account Number in booking details for deferred revenue using the value of the Business Partner Account field of the corresponding Collective Accounts custom setting record. Your business use case, however, may require to use the value of the custom field ON_DebtorNo on the account instead. To support this scenario, you must activate the corresponding global setting.

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

Margin Scheme-Based Bookings

In the context of reselling goods, margin schemes may apply, depending on your tax laws. In such cases, merchants pay taxes on the difference between the sale price and the purchase price of the goods. To support these scenarios, JustOn introduces the Margin Scheme recognition rule. Using this rule, JustOn generates separate booking details for the defined margin and for the position total minus the margin.

Info

The support for margin-based booking details is available as of JustOn 2.68.

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

Field Description
Margin The net or gross margin for the invoice line item, depending on whether it is set as a gross position (Gross Line Item selected).
Margin Tax Rate The tax rate that applies to the margin. The value is taken from the Tax Rate field of the invoice line item.
GL Account The G/L account used for the revenue resulting net amount minus the margin. 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 margin amount. The value is taken from the G/L Account 2 field of the Assignment Rules - G/L Account custom setting.

JustOn applies the Margin Scheme recognition rule if the following conditions are met:

(1) The field Margin of the invoice line item is set.

(2) The field Recognition Rule of the invoice line item is set to Margin Scheme.

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

Info

When applying a margin scheme, taxes apply to the margin amount only. For the original price, that is, the rest of the position total, the tax rate is set to 0.

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

  • one revenue booking detail for the position total net minus the gross margin with the tax rate set to 0,
  • a second revenue booking detail for the margin net amount with the tax rate set to Margin Tax Rate (which is the original tax rate of the invoice line item),
  • a tax booking detail for the tax on the margin net amount.

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

The invoice line item total is split according to the margin, as illustrated in the following examples.

Invoicing net line items and booking net values

Invoice line item:

Field Value
Pos. Total (net) 1000
Tax Rate 0%
Margin 252,10
Margin Tax Rate 19%

Applying the Margin Scheme tax rule, this produces the following booking details:

# Type Booking Account Calculation Amount Tax Rate
1 Revenue G/L Account 1000 - 252,10 * 1,19 700,00 0%
2 Revenue G/L Account 2 252,10 252,10 19%
3 Tax 252,10 * 0,19 47,90 19%
Invoicing gross line items and booking gross values

Gross Line Item on the invoice line item is set and the global setting Enable Accounting in Gross Values is enabled:

Field Value
Pos. Total (net) 1000
Tax Rate 0%
Margin 300
Margin Tax Rate 19%

Applying the Margin Scheme tax rule, this produces the following booking details:

# Type Booking Account Calculation Amount Tax Rate
1 Revenue G/L Account 1000 - 300 700,00 0%
2 Revenue G/L Account 2 300 300,00 19%

If you use gross values when creating bookkeeping data, the global setting Accounting Gross Taxes on First Month is ignored and the tax is always added to the margin booking detail.

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 recreate booking details if 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 finleap connect 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 transferred to accounting systems like DATEV, SAP or Microsoft Dynamics via CSV export or, for DATEV, direct transfer.

Once created, the booking details can no longer be modified or deleted.

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
Best Practice: Generating Bookkeeping Data

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 business entities.

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

Accountants may expect specific references to the operation from which produced booking details originate. To support this requirement, you can use booking texts. They define the content and pattern of this human-readable reference information, and JustOn then populates the Booking Detail field Booking Text accordingly.

Workflow

JustOn generates booking details for balances of the following types: Payment, Refund, Prepayment, Payout, Write-off, Dunning Fee. 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.

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).

Note

JustOn generates booking details for balances that have been created or modified in the past eight days. This is why the payment bookkeeping data job must run at least once per week – otherwise it does not detect all new, changed or deleted balances.

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 Business Entities

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

Correction booking details, like for an amount modification or a deletion, always use the business entity 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 finleap connect with manual assignment

Assume the following actions:

  • Import payment entries from finleap connect, 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. This bookkeeping data is of the type Unbilled Revenue.

When creating and finalizing the corresponding invoices, the existing subscription bookkeeping data is assigned to the invoice and reverted. Consequently, the reverted bookkeeping data offsets the previous unbilled revenue. The actual revenue bookkeeping data for the invoice is generated in addition.

Finally, these records can be transferred to accounting systems like DATEV, SAP or Microsoft Dynamics via CSV export or, for DATEV, direct transfer. Once created, the booking details can no longer be modified or deleted.

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 business entities.

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, Recurring Prorated AVG, 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 subscription bookkeeping data is properly reverted upon invoice finalization.
  • Subscription bookkeeping data is of the type Unbilled Revenue.
  • You can set account numbers or business partner account numbers for subscription bookkeeping data using the Collective Accounts custom setting.
  • 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 invoice bookkeeping data 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 Salesforce 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 business entity, the rule applies only if both the business entity 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 business entity, the rule applies if the business entity 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 invoice bookkeeping data, payment bookkeeping data or subscription bookkeeping data that are not assigned to a revenue-related G/L account. Accounting systems like DATEV or SAP, however, still 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.

Working With Contra Accounts for Invoice Bookkeeping Data
Working With Contra Accounts for Payment Bookkeeping Data

Contra Account Split

Some accounting systems are unable to process booking details that specify both an account number and a contra account number. To support these systems, you can set up JustOn to split booking details on the basis of AccountNo and BpAccountNo, creating separate booking details for the account and the contra account.

Info

The option for creating separate booking details for the account and the contra account is available as of JustOn 2.64.

With respect to the booking detail separation, be aware of the following:

  • JustOn creates separate booking details for the account and the contra account when creating new booking details only. That is, booking details that already exist are not split subsequently.
  • Booking details created for cancellations cannot be split.
  • Booking details that have been specifically created for contra accounts cannot be split along centers.
Implementation details

If the option is enabled, JustOn creates two booking details - one to be booked to the actual target account, and another one to be booked to the contra account. For the additional booking detail, JustOn clones the original fields, with the following exceptions:

  • The field Type of the additional booking detail is set to Contra Account.
  • In the additional booking detail, the field AccountNo is set to the value of the (original) BpAccountNo field.
  • The field BpAccountNo is cleared.

For the split feature to work, the following conditions must be met:

  • The type is not Contra Account.
  • The lookup field Contra Account Booking Detail is not set.
  • The fields AccountNo and BpAccountNo are set.

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 split these booking details - either manually or automatically.

Be aware that booking details that have been specifically created for contra accounts cannot be split along centers.

Managing Booking Detail Center Split
Enabling Manual Center Split
Enabling Automatic Center Split

Invoice 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.

Payment Balance Generation

When exporting invoices, you can select the option Create Payments. Doing so triggers JustOn to create payment balances and to set the originating invoices to Paid or Settled, depending on the invoice class (Invoice or Credit).

Invoice Export History

In addition to the actual export file (CSV or SEPA XML, according to the applied export setting), the export operation produces an Invoice Export History record for each exported invoice. The history holds the following information:

  • Export time
  • Effective payment due date (for installment invoices)
  • File name and link to the exported file
  • Flag stating whether a payment balance has been created
  • Flag that controls whether to prevent repeated exports
  • Flag stating whether an invoice has been exported more than once (forced export)

    The Times Exported field on the invoice shows the export count.

Configuring Invoice CSV Export
Exporting Invoices

SEPA Export

Your organization's business may require to export bank transfer orders for invoices or account balances. 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 open invoices whose payment method is either Bank Transfer or Direct Debit, you use the invoice export mechanism to produce SEPA XML files for debits or credits (depending on whether the invoice states a positive or a negative amount).

Invoice export history

In addition to the actual export file (CSV or SEPA XML, according to the applied export setting), the export operation produces an Invoice Export History record for each exported invoice. The history holds the following information:

  • Export time
  • Effective payment due date (for installment invoices)
  • File name and link to the exported file
  • Flag stating whether a payment balance has been created
  • Flag that controls whether to prevent repeated exports
  • Flag stating whether an invoice has been exported more than once (forced export)

    The Times Exported field on the invoice shows the export count.

You can also export SEPA transfer orders from account balances that are not assigned to an invoice. Upon export, balances of the types Refund or Payout produce SEPA Direct Debit orders, and balances of the types Payment or Prepayment produce SEPA Credit orders. When exporting account balances, the exported balances as well as generated reverse balances (if set up to do so) are locked. Locked balances are exempt from certain business processes like (further) exports or automatic balance assignment.

SEPA Direct Debit

SEPA Direct Debit from Invoices

JustOn exports SEPA Direct Debit orders for invoices if

  • the payment method is either Bank Transfer or Direct Debit,
  • the invoice's open amount is greater than 0, and
  • the invoice has not yet been exported (multiple exports can be forced, however).

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

  • The invoice refers to a business entity.
  • The following fields of the business entity 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 business entity contains the ABI code of the bank.

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 invoice field SEPA Validation Error. The bank transfer order for an invoice is exported if the SEPA Validation Error field is empty.

If there is an active payment instrument set for an account, JustOn uses the following fields of the payment instrument for the SEPA export: IBAN, Direct Debit Mandate Granted and Direct Debit Mandate Reference. If there is no active payment instrument, this information is taken from the invoice or the account.

SEPA Direct Debit from Balances

JustOn exports SEPA Direct Debit orders for account balances if

  • the balance is not assigned to an invoice,
  • the balance amount is greater than 0, and
  • the balance type is Refund or Payout.

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

  • JustOn determines the appropriate business entity according to the business entity configuration. The following fields of the business entity are set:

    SEPA Creditor ID

    IBAN

    Company

  • The following fields of the account are set:

    ON_BankAccount__c

    ON_BankAccountOwner__c

    ON_DirectDebitMandateGranted__c

    ON_DirectDebitMandateReference__c

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

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 balance field SEPA Validation Error. The bank transfer order for a balance is exported if the SEPA Validation Error field is empty.

If there is an active payment instrument set for an account, JustOn uses the following fields of the payment instrument for the SEPA export: IBAN, Direct Debit Mandate Granted and Direct Debit Mandate Reference. If there is no active payment instrument, this information is taken from the invoice or the account.

SEPA Direct Debit With Payment Instruments

JustOn makes use of Payment Instrument records to hold the SEPA Direct Debit Mandate information for accounts. If there is an active payment instrument set for an account, JustOn uses the following fields of the payment instrument for the SEPA export: IBAN, Direct Debit Mandate Granted and Direct Debit Mandate Reference. If there is no active payment instrument, this information is taken from the invoice or the account.

You can create and update account-specific payment instruments based on the SEPA-related information available on the account using a dedicated process. Once created, the payment instruments are accessible via the corresponding related list on the account detail page.

Info

The support for SEPA mandate payment instruments is available as of JustOn 2.68.

Enabling SEPA Mandate Payment Instruments
Configuring SEPA Direct Debit Export
Exporting Bank Transfer Orders

SEPA Credit

SEPA Credit from Invoices

JustOn exports SEPA Credit orders for invoices if

  • the payment method is either Bank Transfer or Direct Debit,
  • the invoice's open amount is greater than 0, and
  • the invoice has not yet been exported (multiple exports can be forced, however).

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

  • The invoice refers to a business entity.
  • The following fields of the business entity 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 business entity contains the ABI code of the bank.

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

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 invoice field SEPA Validation Error. The bank transfer order for an invoice is exported if the SEPA Validation Error field is empty.

SEPA Credit from Balances

JustOn exports SEPA Credit orders for account balances if

  • the balance is not assigned to an invoice,
  • the balance amount is less than 0, and
  • the balance type is Payment or Prepayment.

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

  • JustOn determines the appropriate business entity according to the business entity configuration. The following fields of the business entity are set:

    IBAN

    Company

  • The following fields of the invoice are set:

    ON_BankAccount__c

    ON_BankAccountOwner__c

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

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

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 balance field SEPA Validation Error. The bank transfer order for a balance is exported if the SEPA Validation Error field is empty.

Configuring SEPA Credit Export
Exporting Bank Transfer Orders

DATEV Support

Your organization's business may require to deliver bookkeeping data to DATEV. Technically, there are two ways to do so:

  • Automatically 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

Info

Be aware, however, that the way you use may depend on the type of data you transfer to DATEV.

Invoicing data: Invoicing data refers to actual business transactions that state, in particular, realized revenues or charged taxes and their corresponding booking accounts. If your data involves invoicing data only, you can use both the automatic transfer as well as the export.

Master data: You must use an accordingly configured CSV export if you move master data for accounts like, for example, debtor numbers. This especially applies to new customers that are not yet available in DATEV as "allocation targets".

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 by 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

Be aware that the automatic data transfer to DATEV involves invoicing data only, since the corresponding DATEV interface supports invoice (and cashbook) data only. Invoicing data refers to actual business transactions that state, particularly, realized revenues or charged taxes and their corresponding G/L accounts, and that is represented on booking details created from invoice line items.

To transfer bookkeeping data as generated from payment balances or master data for accounts like, for example, debtor numbers, you must use accordingly configured CSV file exports for booking details or invoices, respectively.

Once the data transfer to DATEV is set up, actually transferring the data from JustOn to DATEV Unternehmen online involves the following repetitive tasks:

  1. Transferring Bookkeeping Data to DATEV

    Be aware that generating the DATEV-specific data records may take time - for 1000 booking details, allow about one hour.

  2. Checking Accounting Documents

  3. Creating and Executing Data Transfer

    Be aware that uploading the accounting documents to DATEV may take time. Depending on the amount of data you transfer, the access token may expire. In this case, restart the data transfer.

DATEV_transfer.png
Transferring bookkeeping data to DATEV

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.

The following table lists some examples:

Booking Detail Accounting Document Accounting Document Item Result
BillingCountry__c BillingCountry__c copy from booking detail to accounting document
Discount__c 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

Transferring Bookkeeping Data to DATEV
Enabling Data Transfer to DATEV

Booking Detail 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

Required custom fields

The JSON example configuration requires additional custom fields:

Object Field Description
Business Entity ClientNumber__c The client number (Mandantennummer) for this business entity.
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).
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",
            "ONB2__BpAccountNo__c",
            "TaxKey__c",
            "BookingDate__c",
            "InvoiceNo__c",
            "",
            "",
            "BookingText__c",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            "",
            ""
        ],
        "headerRow1": [
            "EXTF",
            "510",
            "21",
            "Buchungsstapel",
            "7",
            "TimeStamp",
            "",
            "SV",
            "Admin",
            "",
            "businessentity.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,
                    "length": 60
                },
                "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"
    }
}

Exporting Booking Details
Configuring Booking Detail CSV Export