Under Finance, one or more fixed accounting exports can be configured, which can be retrieved manually or automatically and likewise imported manually or automatically into an accounting system.
The export contains all transactions within the selected period, as specified in the configuration. You can export:
invoice lines
credit note lines
accrued revenue
incoming payments
outgoing payments
payment allocations
When we talk about invoice lines instead of just invoices, it's because it is the lines that are exported as transactions, even if an invoice contains multiple invoice lines. In such cases, the invoice will inevitably result in multiple transaction lines in the export.
Configuring the export
Configuration of accounting exports takes place via the "Setup" button under Finance > Accounting export.
There are two elements in the setup, described below.
1) Configuring columns
First, you need to define which columns you want included in the export. When starting the configuration, Iteras suggests a selection of typical columns: date, transaction description, amount, currency, debit account number, credit account number, as well as two additional fields that can be used as department “tags” (or left blank). You can choose to add more columns or remove some of the default ones, so that only the columns you need are included.
Custom fields are also available in the export. For example, if you have several cash registers for cash payments in-house, you can create a custom field for payments that is exported as a column. You can also place custom fields on campaigns, which are included in the export.
Reconciliation of payments
A few comments should be made about the “payment method” field, which can be used if you want to direct payments from different payment methods (e.g., Visa-Dankort, Mastercard, Payment Slips, etc.) to different financial accounts in your accounting system, with the aim of enabling automatic reconciliation between payments registered in Iteras and payments received in the bank.
When funds are received from card payments depends on the acquiring agreement you have, and it can vary from card to card. By default, fees will be deducted on international cards before the amount is paid out (i.e., you receive the invoice amount minus the fee), which makes automatic reconciliation more difficult. You can ask Nets to pay out the full amount and settle fees monthly. This is the default for Dankort.
It is necessary to know the field values that may appear. These are listed below with the value on the left of the colon and the explanation on the right. You will, of course, only see values for which you have payment agreements.
“manual”: Manual registration of payment
“netsdk-bs”: Payment service
“netsdk-fikort”: BS Payment slip
“american-express”: American Express
“amex”: American Express
“dankort”: Dankort
“visadankort”: Visa/Dankort
“diners”: Diners Club
“edankort”: eDankort
“fbg1886”: Consumer Association of 1886
“jcb”: JCB
“maestro”: Maestro
“mastercard“: Mastercard
“mastercard-debet”: Mastercard
“mobilepay-subscriptions”: MobilePay Subscriptions
“visa”: Visa
“visa-electron”: Visa (this may be both Visa Debit and Visa Electron)
“paypal”: PayPal
“sofort”: SOFORT
“viabill”: ViaBill
“paii”: Paii
“sepadirectdebit”: SEPA Direct Debit
“bankgirot-receivables”: Bankgirot Incoming Payments
“bankgirot-autogiro”: Bankgirot Direct Debit
For card payouts, the value will be:
“card”
… while for others, it will be the same as for incoming payments.
If MobilePay is used for single payments (i.e., not MobilePay Subscriptions), this will not appear in the export. Instead, it will show the card linked to the subscriber’s MobilePay.
2) Configuring export rules
The second part of the setup involves configuring the export rules. Here, you define which data should be exported to which financial accounts.
Export rules are configured in “blocks,” and as many blocks can be set up as needed. For each block, a set of debit and credit account numbers and possibly additional fields are specified, and then you select the transactions you want assigned to those account numbers. This is done using the following options:
Entries
There are four main groups of entries that can be exported:
Invoice/credit note lines: Here you can choose whether to place all invoiced amounts on the same account or split some out – e.g., VAT or discounts, to easily track how much has been given in discounts. It is not possible to define your own categories (but contact us if you have a need not covered by the existing options – if we assess that the need is general, we may add another category).
Accrued revenue: This gives you the daily accrued value for each subscription. For time-based subscriptions, the price is divided over the number of days in the period, and for issue-based subscriptions, it is divided by the number of issues and accrued on the publication date. Note that this export generates a lot of data, as there is a line for every active subscription for each day (so if you have 5,000 subscribers, you get 5,000 x 30 = 150,000 lines per month).
Payment transactions: Incoming payments, outgoing payments, and administrative payment transfers (e.g., payments between subscriber accounts that do not reflect actual amounts moving in or out of the bank account).
Payment allocations/releases: These entries are seen as an alternative to payment transactions, so you use either payment transactions or payment allocations in your accounting export. This requires a bit more explanation: Payments in Iteras are standalone objects that can be allocated in various ways. For example: A subscriber receives an invoice for DKK 100. The subscriber pays DKK 100 towards the invoice. A DKK 100 payment transaction is recorded if you include payment transactions, and DKK 100 is allocated to the invoice if you include payment allocations. Straightforward. But suppose the subscriber calls mid-subscription and wants to cancel. Half of the invoice is credited. This frees DKK 50 of the payment. This does not lead to a bank payout, so nothing happens under payment transactions, but payment allocations record a DKK 50 release. The subscriber also has another partially unpaid invoice from a previous subscription period with DKK 25 due. DKK 25 of the released amount is allocated to this invoice. Again, no bank movement, so no payment transaction, but it appears in payment allocations. The remaining DKK 25 is refunded to the subscriber. In this case, both a payment transaction and allocation of DKK 25 are recorded. Overpayments that are not allocated to any invoice will show as a payment transaction but not as a payment allocation.
There is also an extra category, "Binding Revenue". This is a special category designed for advanced scenarios where revenue equivalent to a subscription's binding period should be recognized at the subscription start. This should not be used without consulting Iteras.
Filtering
For some, distributing the above entries across different debit and credit accounts is sufficient. For others, further filtering is needed.
It is therefore possible to add filtering to the export rule, so that additional criteria must be met for a transaction to be included. If you have multiple business entities (CVR numbers), you will typically need to post them separately. But you might also want to filter at product or campaign level to include specific products or campaigns on certain debit and credit accounts.
If you apply filtering, be careful to include everything. For example, if filtering by product, forgetting one can mean transactions for that product won’t be included. The same goes for campaigns. This will, of course, show up during reconciliation (as bank amounts not linked to any transactions).
Note: There is no validation between product and campaign filtering, meaning selecting a product doesn’t restrict campaign choices accordingly.
Importing into the accounting system
Manual export
If you want to manually export transactions, simply enter the date range for the transactions and then download the file.
Note that Iteras does not track what has been exported and imported into the accounting system. You are responsible for ensuring that transactions are not imported twice or missed. To avoid this, never export and import transactions for a day before midnight has passed, as more transactions could be registered during the day.
Automated export
It is recommended – partly to avoid errors associated with manual exports – to set up an automatic machine-based export of the accounting report via API. Technical setup is described here: https://app.iteras.dk/api/docs/server/financial/
This allows automatic transfer of transactions from Iteras to the accounting system, e.g., daily.
The setup naturally requires help from a technician.