Overview

An overview of the Accounting as a Service accounting module as our bookkeeping and A/R management solution for your business.

The Accounting as a Service accounting module takes care of the debit subledger accounting of your business. The module not only serves to book the sales, taxes and discounts of your orders, but also handles the administration of the capture and refund process as well as the dunning or invoices notification processes towards your customers and takes care of all reconciliation processes.

Main service components

In order to meet the overall business requirements of the module‘s typical end-to-end process starting with the reception of an order and ending with a potential hand over to a debt collection agency, the accounting module is made of the following components:

  • Subledger accounting: When working with the API of the accounting module to handle actions such as invoices/returns/goodwills, these changes will lead to bookings in your subledger accounts all managed the accounting module.
  • General Ledger: All subledger postings as well as some direct postings (like acquirer fees or subscription related accruals are booked into the merchant’s general ledger in Accounting as a Service according to a standard Chart of Accounts. After each period the aggregated G/L balances are transferred into the merchant’s General Ledger either via CSV / XLS file and a manual booking on merchant’s sider or via different APIs (XML / CSV / iDoc)
  • Reconciliation: Accounting as a Service books all receivables, payments, refunds, settlements (incl. fees) as well as bank account statements and reconciles the whole payment flow end-2-end with this information.
  • Captures and refunds handling: Debits/credits and refunds are carried out as a sub-process within the accounting module. Therefore, Accounting as a Service is connected to your payment providers and triggers all captures (optional) and refunds after balancing open debit and credit positions on the debtor account.
  • Booking of incoming payments: For each incoming transaction represented as entry in some settlement file or in the bank account statement from your PSP/bank, the accounting module ensures the transaction to be automatically booked accordingly. Incoming payments by bank transfer are matched automatically using the reference given by the end customer.
  • End customer communication: Accounting as a Service can handle the creation and transmission of invoices, booking confirmations, due date reminder, payment reminders / dunning notices. All generated documents will be based on the data provided via the API in combination with a document template to be defined as part of your onboarding procedure. Transmission of these documents is either handled electronically (i.e. by e-mail) or by mail. All documents are made available via notifications of type accounting/documentCreated.
  • Payment reminder and dunning processes: Where needed, Accounting as a Service provides you with the option to fully take over your commercial dunning process. All relevant information to set up the process will have to be provided as part of your onboarding procedure.
  • Collection agency: Accounting as a Service handles the transfer to collection agencies as well as the booking of collection output (payments, fees, write-offs, extraordinary revenues). In case the process part shall be handled by Accounting as a Service, all related communication with the collection agency in relation to outstanding debts will be handled by the Accounting as a Service team.
  • White-label paypage: Accounting as a Service provides the option to include a paylink or QR code (in case of white letters) on outgoing communication such as dunning e-mails, which enables the end customer to pay directly using a web-based UI / paypage (hosted by Accounting as a Service in merchants branding).
  • MyAccounting: In addition to the API, you can access your data via a web-based UI. In most cases, the user interface will be used by your accounting/finance department for administration purposes as well as by your service center agents.
  • Notifications: Accounting as a Service supports the concept of notifications, allowing the merchant to be informed upon certain events happening inside the system. The concept is based around the idea of having different notification types, for which the merchant can provide a URL to be called back whenever an event of such type occurs. Check out the notification types supported by accounting module to get more detailed information

IMPORTANT NOTE: As for the accounting module, the notifications are essential to be fully functional given that the accounting module handles all incoming requests in an asynchronous fashion. That means, when using the REST API of the accounting module to send requests, the synchronous response that will be provided to you will only contain the internalRequestId which will help you to map upcoming notifications back to your request.

Main entities

Before walking through the list of most important entities of the accounting module, you may want to have a look at the list of Accounting as a Service common main entities shared among all modules. In addition to the common entities, you will most likely have to deal with the following key entities, when interacting with the accounting module:

  • business-code: In Accounting as a Service, each merchant is represented by the existence of one or multiples business codes. Business codes are defined as a tuple of a country and a currency (e.g. DE/EUR, FR/EUR, UK/GBP, etc.) with each code representing an individual legal entity from a tax declaration perspective. In consequence, every order has to be linked to one business-code.
  • order: (See also common description of the entity) An order may be invoiced at once (i.e. single shipment) or using multiple invoices (i.e. multiple shipments).
  • customer: (See also common description of the entity) For each customer a dedicated customer account is created where all booking data related to the customer is saved to.
  • address: Each customer can have one or multiple addresses. These may be differentiated in shipping addresses and billing addresses. With every order, at least a billing address has to be provided.
  • payment instrument: Each orderhas exactly one payment instrument. This payment instrument defines the payment method and all required information to process this payment.
  • invoice: Each invoice represents a shipment / delivery of good which results in the debt of a client and the requirement of the booking of revenue and taxes.

Entity-Relationship-Model

The following simplified diagram illustrates the relationship between the main entities of this module.

ERM-acccounting_overview__entities

Business scenarios

The accounting module is designed for handling normal webshop orders and subscription-based orders, as they are managed by the subscription module. The module strives to cover the needs of the following typical business scenarios:

Scenario 1: Orders for physical or digital products (including shipment / provision of service) without usage of the Accounting as a Service Subscription module

Please note: If you manage your subscriptions yourself you can use this scenario as well. In this case you need to provide contract information described in the create webshop order usecase

Sample scenario

A customer orders a product/licence offered by you as a merchant or your monthly bill-run generates an invoicing record (in case you are managing your subscriptions without using the Accounting as a Service Subscription module). In the following scenario, a customer orders the product and receives it. During the process, the payment fails, and the customer receives dunning notices to settle the debt.

This scenario requires you to provide calls as described by these use cases:

Process flow

A BPMN-like description of the process flow, as outlined in the sample scenario.

High-level process description
An overview using BPMN to describe the process flow
Checkout the BPMN illustration to get an overview of the process, including the various activities and participating main actors.

Scenario 2: Orders getting cancelled

Sample scenario

A customer orders some products/licences and cancels the order before it has been shipped (or the service has been provided). In case of the payment has already been issued, e.g. in case of an online bank transfer payment method, Accounting as a Service issues the refund.

This scenario requires you to provide calls as described in these two use cases:

Process flow

A BPMN-like description of the process flow, as outlined in the sample scenario.

High-level process description
An overview using BPMN to describe the process flow
Checkout the BPMN illustration to get an overview of the process, including the various activities and participating main actors.

Scenario 3: Order with goodwill credit

Sample scenario

A customer orders some products/licences and receives a goodwill credit after the order has been shipped (or the service has been provided). In case of the payment has already been received, Accounting as a Service issues the refund.

This scenario requires you to provide calls as described in these three use cases:

Please note: To create a goodwill, you can either use your own CRM tools and make use of Create goodwill, or you can use our service center UI MyAccounting. In this case you need to be careful in case of e.g. returns which are received after issuing a goodwill credit, Accounting as a Service does not balance returns with good will credits automatically.

Process flow

A BPMN-like description of the process flow, as outlined in the sample scenario.

High-level process description
An overview using BPMN to describe the process flow
Checkout the BPMN illustration to get an overview of the process, including the various activities and participating main actors.

Scenario 4: Order with return

Sample scenario

A customer orders some products/licences and returns parts or the whole order. In case of the payment has already been received, Accounting as a Service issues the refund.

This scenario requires you to provide calls as described in these three use cases:

Process flow

A BPMN-like description of the process flow, as outlined in the sample scenario.

High-level process description
An overview using BPMN to describe the process flow
Checkout the BPMN illustration to get an overview of the process, including the various activities and participating main actors.