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 [accounting/documentCreated] notifications of type .
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.

Involved Systems

Understanding the primary systems that interact with your environment is crucial for a smooth integration with AaaS:

AQI (Accounting Interface)

Purpose: AQI is the middleware that facilitates communication between your systems and the Accounting system.
Functionality: It receives REST API calls, processes them, and forwards the data to the Accounting system. AQI also handles sending notifications generated by the Accounting system, ensuring you stay informed about transaction statuses.
Asynchronous Operations: AQI processes requests asynchronously and buffers data when the Accounting system is temporarily unavailable, ensuring that no information is lost during downtime.

PayGate (PSP Integration Middleware)

Purpose: PayGate connects various Payment Service Providers (PSPs) with the Accounting system, managing payment processing, captures, and refunds.
Credentials and Setup: Your PSP credentials are required for integration, and if your PSP operates asynchronously, a webhook must be set up to notify Riverty of events like payment failures.

Bank Integration

Purpose: Handles bank communications, including receiving account statements and sending direct debit and refund requests.
Requirements: An EBICs user setup is necessary, along with configurations for CAMT.053 and CAMT.054 file formats for statement processing.

Data/File Exchange

sFTP Setup: Data exchange occurs via sFTP, with users generated during onboarding. If a PSP cannot upload settlement files to Riverty’s sFTP, an automated solution is available to pull data from the PSP’s sFTP. All files containing end-customer data will be transfered through this sFTP.

Optical Archive

Purpose: An internal solution for compliant storage of documents and data. All files are securely archived to meet regulatory requirements.

Reporting System

Purpose: Reporting is conducted through PowerBI, offering predefined reports that help manage and analyze business performance.

PayPage (Optional Feature)

Purpose: A Riverty-hosted page that includes a payment widget from the PSP to collect payment details and directly capture open amounts.
Setup: This feature must be configured if chosen, aligning with your PSP settings.

MyAccounting (Customer Service Portal)

Purpose: Customer Service might need more details on an end-customer basis. MyAccounting provides the option to look up end-customer accounts, statuses and payments directly in Accounting as a Service.
Setup: MyAccounting will be installed in any case. To use the feature, we need individual user accounts. Therefore you will be asked to provide the user details for the initial onboarding.

2nd Level Support Requests

Purpose: The 2nd level support system is a dedicated channel for communicating with Riverty’s operational teams.
Functionality: Through this system, you can raise issues, report problems, place booking requests, and request daily business support or information. It serves as the official channel for managing operational support and ensuring smooth business operations.

BSS (Billing and Subscription Service)

Purpose: BSS is an extra module that takes over the billing and subscription service for you. It can handle contract data, usage data and creates order in Accounting as a Service with the respective information.
Setup: You will use this system, if Accounting as a Service takes over your Subscription, Contract and/or Usage Data Management.

Entity-Relationship-Model

This section provides an overview of the entity-relationship model within Accounting as a Service, detailing how various entities interact and are structured. Understanding these relationships is crucial for integrating and managing data effectively within the system.

Client and Legal Entity Structure

Entity relateionship model client.png.jpg

Client to Legal Entities: A single client can have multiple legal entities, each represented as separate business codes within Accounting as a Service. This structure allows for distinct financial and operational tracking across different legal units of the same client.
Legal Entity to Bank and PSPs:
Bank Setup: Each legal entity is linked to exactly one bank, which handles all financial transactions related to that entity, such as incoming payments, direct debits, and refunds.
PSPs (Payment Service Providers): A legal entity can be connected to multiple PSPs to support various payment methods. These PSPs manage the processing of payments and must be configured correctly within the system.
Month-End Reporting: For each business code (legal entity), a single month-end report will be generated, capturing all relevant financial transactions and summaries for that period.

Data Structure Within Accounting as a Service

End-Customer to Orders:

An end-customer can place multiple orders. Each order represents a distinct transaction initiated by the customer.

Order to Shipments/Invoices:

Each order may result in one or more shipments, each generating a corresponding invoice. This flexibility allows for partial shipments and invoicing based on order fulfillment. Please note: only complete line items can be shipped/invoiced. A partial line item shipment is not possible. This means, if you provide an order with 1 line item and the quantity of 3, you can only invoice the entire line item (all three products together). If you want to be more flexible, you need to split up the line item into three positions. However you need to know that in this case you need to remember, which line item was in which position as you will be asked to provide the exact line item number for Returns or Goodwills.

Invoice to Payment:

Single Invoice Payments: Typically, each invoice will have exactly one payment associated with it, ensuring a direct match of payment to billing.
Grouped Payments: Customers may also make a single payment covering multiple invoices, particularly when managing grouped or consolidated payments.

Billing and Shipping Addresses:

Each order includes one billing address and may have one optional shipping address, which are also reflected in subsequent invoices. The correct addresses are essential for tax calculations and compliance.

Payments and Methods:

End-customers can use different bank accounts or payment methods to settle their invoices, providing flexibility in how they manage their payments.

Subledger Accounting:

Each invoice generates one open position in the end-customer's account within the subledger. This entry tracks the outstanding amount until it is fully settled by the customer.

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:

Create webshop order
Invoice webshop order

Process flow

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

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:

Create webshop order
Cancel webshop order

Process flow

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

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:

Create webshop order
Invoice webshop order
Create goodwill

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.

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:

Create webshop order
Invoice webshop order
Return webshop order

Process flow

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