Product documentation
Consumers and companies order more and more through webshops. Often, this requires a (partial) payment which is processed by a Payment Service Provider (PSP). The preferred Microsoft PSP is Adyen, but there are many more like WorldPay, PayPal, Square, Klarna, etc. These PSPs periodically provide detailed reports to their customers on the payments they have processed. This report contains references to the orders, payment authorizations, amounts paid and fees taken. And on the bank statement of their customer, there is usually only a single line for the PSP, referring to the details provided in the file.
When the (web)order is processed in Microsoft Dynamics 365 for Finance and Operations it is considered paid (from an end customer perspective), but the money will only come in when our customer receives the money from their PSP, minus their fee.
Our Microsoft Dynamics 365 for Finance and Operations customers want to reconcile these reports against the order that have received and are processing, to make sure they get paid for everything.
To keep track of what the PSP still owes them, customers can import the detailed transactions report and use that to reconcile against transactions that were brought in from the webshop. If they use Microsoft Commerce customer invoices and settled payments are brought into Microsoft Dynamics 365 for Finance and Operations . If they have a custom interface they may also bring in both the invoice and payment data or they may bring in only invoices. In Banking we have a solution for both.
These imported transactions can be journalized. When both the (web)order and the PSP tranaction have been journalized, they can be picked up by a reconciliation process that settles the transactions, using the Merchant Identifyer (which is usually the (web)order-id), by looking at the description / text field of the journalized transaction.
Periodically, the customer can check which transactions did not yet clear and take action towards the PSP (or reconcile the transactions manually, if applicable).
Through a new set of tables and new GER-file, customers will be able to bring their detailed PSP files into Microsoft Dynamics 365 for Finance and Operations . From there, they will be journalized resulting in financial transactions. These transactions can either be settled against ledger transactions ('Commerce scenario') or against open invoices ('Non-commerce scenario'). In the case of a 'Non-commerce' scenario, we're assuming that all web orders & invoices are created against the same (dummy) customer.
Important
The overall solution looks like this:
In Cash and Bank Management / Payment Service Providers, open the menu 'Payment Service Provider Batches'. To import a new file, click 'Import batch file'. It will create a new batch header and lines.
| Header | Description |
| Batch | Unique number / Identifier, coming from the file |
| Status | Status of the batch (Imported, Journalized) |
| Service provider | Payment Service Provider used for the import |
| Created by | User that imported the file |
| Created date and time | Time the file was imported |
| Lines | Description |
| Line | Line number |
| Type | Type of transaction line, as specified by the PSP |
| PSP Reference | Identifier for the Payment Service Provider. Might be meaningful to our customer, but not necessarily |
| Merchant Reference | Method of payment used by the client paying. Needs to be present in the Methods of Payment table of Microsoft Dynamics 365 for Finance and Operations |
| Payment Specification | Further detailing of the method of payment |
| Created date and time | Time the line was created |
| Modification reference | Internal reference of Payment Service Provider. Probably meaningless to our customer |
| Modification Merchant reference | Additional Merchant Reference |
| Currency | Currency of transaction |
| Gross credit | Gross credit amount |
| Gross debit | Gross debit amount |
| Commission | Commission amount taken by PSP |
| Markup | Markup taken by PSP |
| Fee | Fee taken by PSP |
| Interchange | Interchange fee taken by PSP |
| Net credit | Net credit amount (to be paid to our customer) |
| Net debit | Net debit amount |
After importing, the batch can be journalized by clicking the button 'Journalize'. It will create a new Journal, using the Journal Name specified on the PSP. And each line from the batch that has a type which is to be journalized, will create a line in the journal. The status of the PSP batch will change to 'Journalized'. If the user sets the 'Post Journal' to 'Yes', the journal will immediately be posted. If set to 'No' the journal can be reviewed and manually edited before posting.
In the case of the Commerce scenario, only ledger accounts will be used. The offset ledger account will always come from the Journal Name as specified on the PSP. The Net credit amounts will be posted to the 'Account' specified in the PSP line mapping. And the sum of all the fees will be posted to the 'Cost Account' as specified in the PSP line mapping.
In the case of the Non-commerce scenario, the customer specified on the PSP will be used for the credit and the debit transactions are created from the Net credit amount and the sum of the fees.
The created journal can be viewed by clicking the 'Ledger Journal' button at the top. If the Ledger Journal has not been posted yet, it can be deleted. Such deletion will change the status of the PSP batch back to 'Imported'.
Posted transactions can be settled automatically, using a common identifier. For ledger transactions this identifier is looked for in the description field, and for customer payments the identifier is the invoice number.
Go to Cash and Bank Management / Payment Service Providers / Automatic Settlement. In the dialog, select a Data Interval that the settlement process should consider. Use e.g. Current Year - to date or Current and Previous period.
Banking will consider the ledger accounts defined in General Ledger Parameters / Ledger Settlements and group them by their ledger description. For such a group, all debits and credits are summarized and if the total sum is 0.00 all transactions in the group are settled.
Go to Accounts Receivable > Period tasks > Settlement > Automatic Customer Settlement. In the dialog, select the appropriate way to define the date:
| Field | Description |
| Latest date | The most recent date of any of the transactions in a group that is settled. Usually the payment date, because it happens after the invoice |
| Today's date | The date of today, i.e. the day the process is run |
| Selected date | A manually selected date |
| Show info | Shows detailed information on the transactions considered, grouped and settled. Typically used during implementation or if a particular invoice & payment are not picked up by the automatic process |
The Payment Service provider functionality is licensed via a separate license key.
With Adyen being the preferred PSP of Microsoft, our solution is based on Adyen and there is an out-of-the-box Adyen GER file available.
A new generic Payment Service Provider model and a specific implementation of Adyen have been added to the HSO Banking solution. To validate whether they have already been imported, go to the workspace Electronic Reporting and select the tile Reporting configurations. It will open a tree control showing the available configurations. Find DYS Payment Service Provider model. It has a PSP destination mapping and a Adyen CSV Format associated with it.
Import can be done in two ways.
1. Import our Banking Solution in the solution tab of Lifecycle Services (LCS), this will put the GER files into the GER Configuration tab. Download them and import them manually.
2. Import via the HSO Electronic reporting repository.
The HSO Banking GER files are available in the HSO Electronic reporting repository but can also be downloaded from the GER Confiugration tab in the Asset Library in Lifecycle Services (LCS).
PSP formats link the GER format to a format that can be selected on a PSP.
In Cash and bank management > Setup > Payment service providers > Payment service provider formats link a ER-configuration to a format.
| Field | Description |
| Format | A user friendly name identifying a PSP format |
| Import format configuration | The configuration as defined in Electronic Reporting |
Customers can have multiple Payment Services providers and they may be set up differently. The Payment Service Provider setup consists of 2 parts: a header definition and a line definition. On the header the importing format, Journal Name and (optionally) the default customer are defined. On the lines, the ledger accounts for the various transactions are defined.
In Cash and bank management > Setup > Payment service providers > Payment service provider define the PSPs the customer is working with. The PSP is linked to a format, a journalname and ledger accounts.
| Header | Description |
| Service provider | The PSP the customer is working with |
| Import format | The import format to be used for this PSP |
| Journal name |
The journal name to be used when ledger transactions are created for this PSP Note |
| Offset customer | (Optional) the customer to be used in case of a non-Commerce scenario |
| Field | Description |
| Type | The type of line as defined in the file of the PSP. Different PSPs may have different types. At least define a mapping for each type that needs to be journalized. To make sure nothing gets overlooked or forgotten, best to define all incoming types. |
| Account type | The account type for the 'Amount to be received from the PSP' |
| Account | Ledger account for the 'Amount to be received from the PSP' |
| Cost Account | Ledger account to post the PSP costs directly related to this type of transactions |
| Journalize | Indicates if rows of this type should be journaized or not. Some types of lines (e.g. Opening Balance) should probably be excluded from journalizing. |
Create a Journal name of type 'General Ledger' and give it a fixed offset account of type 'Ledger'
General ledger > Ledger setup > General ledger parameters > Ledger settlements
On tab 'Ledger settlements' activate the checkbox 'Enable ledger settlements' and add the ledger accounts that need to be auto-settled. This will typically be the ledger account specific as the offset account on the PSP Journal Name.
| Question: | ... |
| Answer: | ... |