Skip to content

Payment Tracking

Accounting Support

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

Actively collecting payments

Payment collection, as the name suggests, generally involves all processes or tools for actively collecting money from customers – instead of just waiting for them to pay.

Generally, you distinguish between procedures for triggering outstanding payments within the regular due terms and those for collecting overdue receivables.

Tool Description
Automatic payment collection JustOn can store credit card or bank account data and, if supported by the payment provider integration, use it to automatically collect payments for open invoices.
SEPA payment orders JustOn exports bank transfer orders – SEPA Direct Debit and SEPA Credit – for invoices or account balances, which can directly be used by banks for triggering the corresponding payment operations.
Tool Description
Account statements Account statements are reports that show the billings and payments of a given account for a specific time period. Businesses can use them to remind customers of sales that have not yet been paid, without expressly stating an overdue receivable and without starting a dunning process.
JustOn implements account statements using specific statements that summarize the account's balances.
Dunning statements Dunning statements officially notify customers of overdue payments. According to the overdue status, these notifications can progress from friendly reminders to firm warning letters.
JustOn implements dunning process support based on configurable dunning statements.
Using multiple dunning levels, you can build your individual dunning escalation scenario.
Debt collection If the dunning communication remains unfruitful, businesses may turn customers over to debt collection agencies, who usually proceed to take other collection options.
To support this option, you can specify the name of a debt collection agency when configuring your dunning levels. When set, JustOn copies the name to the invoice, where it is then available for further custom processing.
Individual value adjustment Individual value adjustment (or IVA) is an accounting procedure for devaluing receivables, for example, outstanding payment requests for invoices.
JustOn implements IVA for invoices using specific bookkeeping data.
Write-off Write-off is an accounting procedure for reducing or completely removing the value of an asset or receivable – for example, an uncollectible payment for an invoice.
JustOn supports writing off invoices using specific balances that count against the invoice balance.

Payment Entries

JustOn registers invoice-relevant payment transactions that have occurred in external systems as payment entries. Each payment entry record represents a payment operation registered at a bank.

There are two ways to acquire payment entries:

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

Matching payments

Users assign the payment entries to invoices, which creates corresponding balance records. As a consequence, this reduces the payment amount of the invoice, or, if balanced out completely, sets the (open) invoice Paid.


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.


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.
  • If a payment entry matches a cancellation invoice or a canceled invoice, JustOn uses the account of the originally canceled invoice as the matching target. Any created payment balances will be assigned to this account, without relating to the canceled invoice or the cancellation invoice.
  • In case of a chargeback, JustOn includes invoices of the statuses Paid, Settled, Closed and Canceled to find a likely match.
  • 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


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

Settling a credit of -10 €


Credit Debit Payment Amount
10 -10


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


Credit Debit Payment Amount
10 10


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.


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.


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.

To support return debits or other chargeback operations, JustOn allows to handle chargeback payment entries. Assigning a chargeback payment entry creates a balance of the type Chargeback, which offsets a payment balance. Consequently, assigning a chargeback balance to a paid or settled invoice will set the invoice back to the status Open.

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.

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