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.
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:
accounting/documentCreated
.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.
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 order
has 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.The following simplified diagram illustrates the relationship between the main entities of this module.
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:
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
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:
A BPMN-like description of the process flow, as outlined in the 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:
A BPMN-like description of the process flow, as outlined in the 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.
A BPMN-like description of the process flow, as outlined in the 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:
A BPMN-like description of the process flow, as outlined in the sample scenario.