Revolving credit product – Reminder and collection process
Reminder and collection process (V2)
Enfuce standard credit product setup includes an automated reminder and collection flow that allows the issuer to effortlessly remind the customers of any overdue balance which decreases credit risk. Our comprehensive suite of reminder and collection events offers diverse rule options, empowering issuers to tailor a reminder and collection flow that best suits their needs and adheres to various regulatory standards across different markets.
The reminder and collection process is automated and all actions are triggered according to predefined rules set during the implementation project.
As described in a separate section, balances on a credit product are segregated and age as the billing cycle closes and due dates pass. The reminder process is triggered if a balance remains on the minimum-to-pay (“MTP”) accounts after the delinquency date has passed.
Reminder Events and Actions
Enfuce has implemented a series of reminder and collection events, from which the issuer can pick the ones needed to create a process flow designed for their needs. For every event, the issuer can choose what actions that event should perform. There are 7 reminder events and one collection event. Through our APIs and MyEnfuce platform, issuers can conveniently monitor the status of posted events, including delinquency status.
These events are seamlessly integrated into an event chain, enabling issuers to define threshold days between events. The Enfuce system diligently calculates and tracks the days, ensuring timely posting of subsequent events on the account. The events can also be set on fixed dates. The calculation for triggering the first event starts from the delinquency date. There can also be threshold values for the reminder events for example, overdue debt under 5£ will not trigger a reminder 2 event.
Reminder Process Overview
The issuer can choose which actions to add to the selected events.
| Reminder Actions | Action Description |
|---|---|
| Soft block - Block card usage | Card usage on the account level is blocked. In case of full incoming payment, the block is removed automatically. |
| Charge a reminder fee | 2 different reminder fees can be set. |
| Create a reminder file | The issuer can send an official reminder letter to the cardholder. |
| Trigger a push notification | The issuer can forward the information via SMS, e-mail, paper letter or through the app. |
The collection event has a following default set of actions.
| Reminder Actions | Action Description |
|---|---|
| Account status change: Account in collection | Account status is changed. |
| Block interest posting | Interest is not posted on the next billing cycle end. |
| Stop invoicing | Account is removed from the statement generation. |
| Hard block - Block card usage | Card usage on the account level is blocked. Requires a manual block lifting. |
| Cards No Renewal | Cards will not be renewed whilst the account is in collection status |
The card account and balance will remain in the Enfuce system on the overdue balance accounts even after the status has been updated to “Account In Collection”, and the issuer can continue to post payments to the account to reflect any potential payments the customer has made to the collection agency. Those can be finally written off from the accounts as well. See more information on the Balance write off section of the document.
Reminder fees
When sending reminders, the Enfuce system can also post reminder fees based on predefined values. Country-specific rules and regulations apply, but the system supports reminder 1 (transaction type REM1) and reminder 2 (transaction type REM2) fees for posting.
In case of any erroneous postings, these can be reversed using the Update Transaction API with the original document ID. Reversals are posted to the account as credits and are applied to debts according to payment priorities, such as starting with the oldest debts.
Example Use of the Events and Actions
Events can be triggered X days after either the billing cycle ends or the due date.
| Event | Actions |
|---|---|
| Reminder 1 | Notify the cardholder on passed due date right after. - Trigger a push notification |
| Reminder 2 | Notify the cardholder on upcoming reminder. - Trigger a push notification |
| Reminder 3 | Hard/strong reminder. - Create a reminder file - Soft block card usage - Charge a fee |
| Reminder 4 | Notify the cardholder on the second hard/strong reminder in case of no payment. - Trigger a push notification |
| Reminder 5 | Second hard/strong reminder. - Create a reminder file - Charge a fee |
| Reminder 6 | Warning, collection notice will be sent in case of no payment. - Trigger a push notification |
| Reminder 7 | Collection notice - Create a reminder file |
| Send to Collection | Send to collection - Account status change: Account in collection - Block interest posting - Stop invoicing - Hard block - Block card usage - Card no renewal |
Reminder Statuses in the API
Account reminder statuses can be viewed from the Get Account API under “reminders” section of the call.
Reminder process related statuses visible through the account API:
| Reminder event | Values | Definition |
|---|---|---|
"reminder1TriggerDate" | YYYY-MM-DD | Date when the reminder event has been/will be triggered |
"reminder2TriggerDate" | YYYY-MM-DD | Date when the reminder event has been/will be triggered |
"reminder3TriggerDate" | YYYY-MM-DD | Date when the reminder event has been/will be triggered |
"reminder4TriggerDate" | YYYY-MM-DD | Date when the reminder event has been/will be triggered |
"reminder5TriggerDate" | YYYY-MM-DD | Date when the reminder event has been/will be triggered |
"reminder6TriggerDate" | YYYY-MM-DD | Date when the reminder event has been/will be triggered |
"reminder7TriggerDate" | YYYY-MM-DD | Date when the reminder event has been/will be triggered |
"collectionTriggerDate" | YYYY-MM-DD | Date when the collection event has been/will be triggered |
"disableReminderProcess" | TrueFalse | "False" when it’s enabled"True" when the reminder processes has been stopped. This is final status so the status cannot be set back to "False" |
"reminderStatus" | "WAIT""REMINDER1_SENT""REMINDER2_SENT""REMINDER3_SENT""REMINDER4_SENT""REMINDER5_SENT""REMINDER6_SENT""REMINDER7_SENT""SENT_TO_COLLECTION""STOPPED""DONE" | This status will be empty when there are now overdue invoices. Once invoice has been reached overdue on the delinquency date the status will be "WAIT".After that it will state the most recently sent reminder or collection event. If reminder process has been manually stopped it will show in "STOPPED" status. See further information in the exception handling section.Reminder status will marked as "DONE" when payment is received to clear the process. Similarly it will marked as “done” if the next reminder event stays under threshold. Please see classifiers section for more information. After the last reminder event for the process has been triggered the final status will be always set as "DONE" on the following day. |
"accountCardBlocks"SOFT_BLOCKHARD_BLOCK | "FALSE"“TRUE" | "FALSE" status is shown when the cards can be used.Once the "SOFT_BLOCK" is set to "TRUE" then the cards are blocked on the account level.At the time of collection sending “hard block" is set to "TRUE" |
Incoming Payments and Recovering from the Reminder Process
When a full payment is received, the account exits the reminder process. If the payment covers the past due balances, the reminder process is automatically discontinued. Subsequently, any soft blocks on the cards are promptly lifted, allowing the cardholders to resume spending without interruption.
However, if only a partial payment is made, the reminder process persists, and the account remains classified as delinquent until the outstanding overdue balance is settled in full.
In cases where the account has progressed to the collection phase, an incoming payment does not automatically remove it from the process, and the card remains blocked. To restore card functionality, manual intervention is required to lift the hard block through Account API/MyEnfuce portal.
Managing Exceptions and Special Circumstances
At times, deviations from the standard reminder and collection process are necessary to address exceptional circumstances effectively. Enfuce recognizes the importance of flexibility in managing such situations and has devised a range of tailored actions to assist issuers in navigating these deviations seamlessly.
Enfuce’s system empowers issuers to identify and manage exceptional cases by utilizing a series of predefined actions. These actions are specifically designed to address various scenarios that may arise, allowing issuers to handle each situation with precision and efficiency.
To initiate these exceptional actions, issuers can easily flag accounts by setting the classifier value ‘under investigation’ to ‘YES’. This classification serves as a clear indicator within the Enfuce system, signaling that the account requires special attention and prompting the activation of the appropriate actions to address the unique circumstances at hand.
By leveraging these tailored actions and classifiers, issuers can effectively manage deviations from the standard flow, ensuring that each situation is addressed promptly and appropriately.
Exception actions through API or MyEnfuce Portal
All the below listed exception action are reflected in the DWH files on the next day.
| Action | How |
|---|---|
| Under investigation | "underInvestigation" to be set “true” through Update a credit account API Account under investigation will be ignored in the reminder process. |
| Set the minimum-to-pay percentage to 0 | "minimumToPay" "percentage" to 0 through Update a credit account API |
| Block interest posting | "interestPostingEnabled" to “false” through Update a credit account API |
| Block / Unblock cards | Card blocks on the account level can be manually lifted by changing the "accountCardBlocks" values from “SOFT_BLOCK” or “HARD_BLOCK” into “false” at the Update Account API or vise versa, blocks can be manually set back on “true” from there. |
| Stop the reminder & collection process | “disableReminderProcess" to “true” through Update a credit account reminder data API |
| Change the reminder dates | "reminder1TriggerDate" in “YYYY-MM-DD format through Update a credit account reminder data API |
Sample use cases
This chapter describes how the exception actions can be used in different use cases.
Deceased Customers and bankruptcy
In case of the death of the cardholder or a bankruptcy of an company, the issuer can set the expiry date on the customer level via Update Private Customer API. When the customer has deceased, the account will be frozen. This is done by setting a classifier “under investigation” value as “true” for the account. Accounts with this value will be excluded from the reminder process.
Additional Classifier values that can be changed via API:
- set the minimum-to-pay percentage to 0
- block interest posting
The changes are reflected on the next day’s DWH files, so the issuer can keep track of these customer cases.
In some countries, the issuer can sell the remaining debt to the collection agency. The issuer can manually change the account status to “Send to collection”.
The account balance from the death date can be found in the Account Balance DWH files.
Personal bankruptcy, payment plan
When the cardholder ends up in personal bankruptcy, the “under investigation” classifier can be used to stop the reminder process. This is done by setting a classifier “under investigation” value as “true” for the account.
On top of the classifier status update, these values can be changed via API:
- set the minimum-to-pay percentage to 0
- block interest posting
The cardholder has to follow a payment plan when the application is approved. Enfuce supports payment plans with the instalment feature, which can be configured separately.
Disputed invoice
When a cardholder encounters ambiguity or disagreement regarding their credit card invoice, they have the right to dispute it. Upon initiating a dispute, the invoice in question is flagged for investigation.
To facilitate this process, the Enfuce system features an ‘under investigation’ classifier. By assigning a “true” value to the ‘under investigation’ classifier for the respective account, the issuer can indicate that the invoice is currently under review, ensuring proper attention and handling.
In tandem with initiating the dispute, this allows for the temporary suspension of the reminder process associated with the disputed invoice. This prevents any unnecessary reminder notifications from being sent while the dispute is actively being addressed, offering customers a hassle-free experience during the investigation period.
Once the dispute is resolved, whether through clarification, adjustment, or resolution of the discrepancy, the “under investigation” classifier can be set off by changing it into “false”. If payment is made during the dispute resolution process, the reminder process automatically discontinues, ensuring that customers are not inundated with redundant reminders.
Customer needs more time to pay their invoice
When a customer contacts the customer support seeking an extension for payment of their credit card invoice, Enfuce’s flexible reminder process offers the ability to accommodate their request seamlessly. This adjustment can be easily facilitated via API integration or directly through the user-friendly interface of MyEnfuce.
By modifying the threshold waiting period, the initiation of the reminder process can be effectively postponed, ensuring that our customers have the necessary flexibility to manage their financial obligations. This feature becomes particularly advantageous when the next scheduled reminder event is not bound to a fixed date.
Moreover, for cases where fixed dates are employed within the reminder system, we offer the capability to temporarily halt the reminder process altogether. However, it’s essential to note that by opting for this option, the reminder process will not resume automatically in the event the customer fails to make the payment promptly.
Manual Sending to Collection
In some cases, the issuer might need to change the account status in the Enfuce system to “Send to Collection”. When the account status is changed, it will trigger the following actions in the Enfuce system:
- Account status change: Account in collection
- Block interest posting
- Stop invoicing
- Hard block - Block card usage
Balance Write-offs
Sometimes the debt collection fails for one reason or another, and the issuer needs to write off the debt either partially, or in full. The reasons could be customer bankruptcy or insolvency, fraud or even death of the customer.
Write-off of a card account debt is done through Transaction API. The issuer will define the write-off amount (either full balance or partial balance) and have a full audit trail of the balance types that have been written off (principal, fees, interest). The information can be found in the Account Balance DWH files.
Enfuce provides 4 different balance write-off transaction types (BWO1, BWO2, BWO3, BWO4), which the issuer can use to segregate the write-off reasons in their reporting. As the balances are written off, they are posted to specific Write-off GL accounts, which will allow the issuer to have the necessary data for bookkeeping. For regulatory reporting, more details can be added to the transaction’s text section, which will be then reflected in the DWH reports and can also be queried via transaction API. For example, in case only one transaction needs to be written off, the transaction ID can be inserted into the text section of the write-off.
In case of a positive balance write-off, the write-off is done through a support ticket to Enfuce. Our specialists will ensure that the write-off is done correctly.
Reminder & Collection in Data Warehouse files
The issuer can see the account delinquency level (DLQ_LEVEL) and reminder statuses from the Account Properties files and the monthly statement files. The reminder fees are presented in the Transaction file. All the reminder exception actions are presented in the Account files. On top the files all the reminder statuses can be seen in the Get Account API or in by checking the Account in MyEnfuce.
The DWH files are incremental, capturing any changes to accounts that were recorded the previous day. Account properties file includes ‘Reminder Sent’ events, allowing issuers to track the account’s dunning status. Additionally, if the reminder process does not proceed because the values fall below the threshold, a corresponding event will be triggered and reflected in the DWH file. None of the classifiers have any values by default, so if events haven’t been posted the values are empty.
Following classifier values will be updated in the statement and Account properties DWH files:
| Classifier Name | Code | Values Name/Code | Description | API/MyEnfuce |
|---|---|---|---|---|
| Reminder Process Status | REM_CL_STATUS | - Reminder 1 / 1 - Reminder 2 / 2 - Reminder 3 / 3 - Reminder 4 / 4 - Reminder 5 / 5 - Reminder 6 / 6 - Reminder 7 / 7 - Collection / COLL - None / N - Stopped / S | Reminder 1 classifier will be triggered along the event to be visible on the next morning’s DWH file. Reminder classifier will be set as ‘None’ when the past due balances are paid, even if the account would be in collection. ‘Stopped’ is final status that can be manually set. | Reminder trigger dates are visible in the Get Account API It is possible to amend the threshold times and stop the reminder process in Update a Credit Account Reminder data API |
| Account Card Block (Soft block) | INV_CARD_BLOCK | - No / N - Yes / Y | If set to ‘Yes’ then all cards for the account are blocked for the transactions. This will be automatically lifted when overdue balance has been paid. | Card statuses are visible in the Get Account API Cards can be manually blocked/unblocked in Update a Credit Account API |
| Card Hardblock | CARD_HARDBLOCK | - No / N - Yes / Y | If set to ‘Yes’ then all cards for the account are blocked for the transactions. This will not be automatically lifted by the system | Card statuses are visible in the Get Account API Cards can be manually blocked/unblocked in Update a Credit Account API |
| CL. Under Threshold | CL_THRESH | - None / N - Yes / Y | In case the overdue balance is under the threshold for the next reminder event to be triggered the system will set the under threshold classifier into ‘Yes’ for the day and clears on the next day. | N/A |
| Delinquency Level | DLQ_LEVEL | No Debts / 0 Due / 1 Past Due 0-30 / 2 Past Due 31-60 / 3 Past Due 61-90 / 4 Past Due 91-120 / 5 Past Due 121-150 / 6 Past Due 151-180 / 7 Past Due 181-210 / 8 Past Due 211-240 / 9 | Delinquency level is shadowing the aging of the balances in 30 days past due slots. | N/A |
| Block Interest Posting | BLOCK_INT_POSTING | No / N Yes / Y | Revolving or overdue Interests will not be posted in case the block interest posting has been set to ‘Yes’. | Visible in the Get Account API Possible to update in Update a credit account API |
| Under Investigation | UNDER_INVESTIGATION | No / N Yes / Y | When under investigation has been set to ‘Yes’ the reminder process for the account will be stopped for the time being. | Visible in the Get Account API Possible to update with Update a credit account API |
Reminder File Content
The issuer can choose file creation as one of the actions to be attached to the reminder events. The file will be created when an event is posted to the Enfuce system, with this action attached to it. The file is delivered to the customer’s SFTP. The issuer can then use the file to create a reminder letter and send it to the cardholder.
Reminder XML file naming
- Enfuce_REMINDER_1_institution_yyyy-mm-dd_x_yyyymmdd.xml
- Enfuce_REMINDER_2_institution_yyyy-mm-dd_x_yyyymmdd.xml
- Institution
- Issuer number
- yyyy-mm-dd
- Reporting date to identify for which date the content was generated
- X - running number to indicate the consisting file
- File splitting is used to avoid big files with high volumes
- The maximum amount of records: 99 per file
- yyyymmdd_hhmmss
- Timestamp of the file generation time in the Enfuce system
The file content
| Section | Field Name | Details | Values |
|---|---|---|---|
| file | fileDate | File creation date | YYYY-MM-DD |
| file | fileId | Running number sequence (file split) | 1… |
| file | institutionId | Issuer number | 111111 |
| file | institutionName | Issuer name | Company Ltd |
| file | NumberOfRecords | Number of records in the file | 1…99 |
| file | receiver | Receiver where the file will be sent | Issuer |
| records / record→ | recordId | Record sequence number in the file (max 99) | 0000001… |
| record / account→ | accountNumber | Customer account number | |
| account | accountName | Customer name (Commercial or Private) | Company ltd or John Smith |
| addInfo | type - value | Date plan configuration code | FUNCTIONAL_DATES - FLTACCPRIV01 |
| addInfo | type - value | GL plan configuration code | GL_PLAN - FLTACCPRIV01 |
| addInfo | type - value | Tariff plan configuration code | TARIFF_PLAN - CRDACCPRIV01 |
| account | productName | Product name | Product name configured in Enfuce payment platform - Prepaid, debit, credit, fleet etc. |
| account | productCode | Product code | CREDIT |
| account | status | Status of the account | 00 |
| ← / record / account | |||
| record / balances → | amount, type | Balance type with amount | TOTAL_BALANCE |
| balances | amount, type | Balance type with amount | TOTAL_DUE DUE PAST_DUE OVD_01 OVD_02 TOTAL_BALANCE OPENING_BALANCE INVOICE_AMOUNT INVOICE_DUE_AMOUNT |
| ← / record / balances | |||
| record | billingDate | Billing date | YYYY-MM-DD |
| record | billingPeriodEndDate | Billing period end date | YYYY-MM-DD |
| record | billingPeriodStartDate | Billing period start date | YYYY-MM-DD |
| record / client → | addInfos / AddInfo | type / value | |
| client | clientNumber | Issuer number | |
| client | companyName | Issuer name | Company Ltd |
| client | Issuer email address | company@mail.fi | |
| client | locale | Client country location | fi_FI en_GB sv_SE no_NO is_IS |
| ← record / client | |||
| record | creditLimit | Account credit limit | 0.0 |
| ← record / deliveryAddress | addressLine1 | Street address | Street 1 |
| deliveryAddress | city | City | Helsinki |
| deliveryAddress | countryCode | ISO alpha-3 code | FIN |
| deliveryAddress | countryName | Country name in letters | Finland |
| deliveryAddress | zipCode | Postal code | 00100 |
| deliveryAddress | addressLine2 | Street address / P.O. box | Box 100 |
| ← record / deliveryAddress | |||
| record | dueDate | Invoice due date | YYYY-MM-DD |
| interestRates / interestRate → | code | Interest rate code | INT_OVD |
| interestRate | effectiveDate | Start date | YYYY-MM-DD |
| interestRate | name | Interest name | Interest Rate - Overdue MTP |
| interestRate | value | Interest rate percentage | 00.00 |
| ← interestRates / interestRate | |||
| fees / fee -> | code | REM1_FEE REM2_FEE | |
| effectiveDate | Posting date | YYYY-MM-DD | |
| name | Fee name | Reminder 1 Fee Reminder 2 Fee | |
| feeBase | Set fee value | 0.0 | |
| ← fees / fee | |||
| record | minimumToPayPercentage | Minimum percent to be paid | 100 |
| record | paymentTerm | Payment terms | PAY_TERM - 1…31 |
| record | recordId | Record sequence number in the file | 0000001 |
| record | referenceNumber | Payment reference number | 001234567890011 |
| ← records / record | |||
| ← file |
Reminder and collection process (V1)
The standard credit product setup includes an automated reminder and collection flow that allows you to effortlessly remind your customers of any overdue balance. This decreases credit risk and is required in many markets to be compliant with legislation and regulation. The default process is that an end-customer is reminded twice of the overdue debt before sending the debt to collection.
The reminder and collection processes are automated and all actions are triggered according to predefined rules that are set during the implementation project. The rules you get to define are:
- How many days after the due date should the first reminder be sent?
- What is the fee for the first reminder?
- How many days after the due date should the second reminder be sent?
- What is the fee for the second reminder?
As described in a separate section, balances on a credit product are segregated and age as the billing cycle closes and due dates are passed. If there remains a balance in the minimum-to-pay (MTP) accounts the day after the due date has passed, the reminder process is triggered.
First reminder for an overdue invoice
Enfuce will start calculating the reminder days when there is an unpaid due balance after the delinquency date. The delinquency date is set per issuer definitions during the implementation project as days after the due date. The calculation start date is indicated in the daily data export files by the account property ‘CL_REM1_ST’ which is updated to ‘W’ (Waiting) after the due date. The account is constantly monitored and the calculation stops in case the customer makes a payment that covers the entire overdue balance. If a payment is received before the reminder is sent, the ‘CL_REM1_ST’ property is updated from ‘W’ (Waiting) to ‘N’ (No) during the End of Day processes.
If the customer does not pay the overdue balance by the time the predefined amount of days since the delinquency date has passed, the account property is updated from ‘W’ (Waiting) to ‘S’ (Sent). Simultaneously the potential fee for the first reminder is posted on the card account. Sending reminder 1 is also the default threshold for when the account will be considered blocked, i.e., all authorisations will be declined due to delinquency. While the authorisations are declined, the status of the account or cards will not change. When the full payment is received, the account and cards will be unblocked immediately when the payment is posted to the card account.
Second reminder for an overdue invoice
As soon as the account property ‘CL_REM1_ST’ property is updated to ‘S’ (Sent), Enfuce will start calculating the days for the second reminder. This calculation start is reflected in the account property ‘CL_REM2_ST’ which is updated to ‘W’ (Waiting). The same monitoring of the account applies for the second reminder and the calculation stops in case the customer makes a payment that covers the entire overdue balance. If a payment is received before the reminder is sent, the ‘CL_REM2_ST’ property is updated from ‘W’ (Waiting) to ‘N’ (No).
If the customer does not pay the overdue balance by the time the predefined amount of days since the first reminder was sent, the ‘CL_REM2_ST’ account property is updated from ‘W’ (Waiting) to ‘S’ (Sent). Simultaneously the potential fee for the second reminder is posted on the card account. As the second reminder is actualised (i.e. ‘Sent’), the calculation for sending to collection starts.
Collection process for revolving credit
As soon as the account property ‘CL_REM2_ST’ property is updated to ‘S’ (Sent), Enfuce will start calculating the days for sending to collection. This calculation start is reflected in the account property ‘CL_COLL_ST’ which is updated to ‘W’ (Waiting). The same monitoring of the account applies for sending to collection and the calculation stops in case the customer makes a payment that covers the entire overdue balance. If a payment is received before sending to collection, the ‘CL_COLL_ST’ property is updated from ‘W’ (Waiting) to ‘N’ (No).
If the customer does not pay the overdue balance by the time the predefined amount of days since the second reminder was sent, the ‘CL_COLL_ST’ account property is updated from ‘W’ (Waiting) to ‘S’ (Sent).
Sending to the collection will trigger the following actions at Enfuce:
- Interest accrual will be discontinued
- Card account will be excluded from statement generation (as debt collection is expected to be continued by the collection agency)
- Account status is updated to ‘Account In Collection’
Based on the updated ‘CL_COLL_ST’ account property in the daily data export files, you can take action and initiate the collection process with your chosen debt collector. The card account and balance will remain in the Enfuce system even after the status has been updated to ‘Account In Collection’, and the issuer can continue to post payments to the account to reflect any potential payments the customer has done to the collection agency.
Balance Write-offs
Sometimes the debt collection fails for one reason or another, and the issuer needs to write off the debt either partially, or in full. The reasons could be customer bankruptcy or insolvency, fraud or even death of the customer.
Write-off of a card account debt is done through Transaction API. The issuer will define the write-off amount (either full balance or partial balance) and have a full audit trail of the balance types that have been written off (principal, fees, interest). The information can be found in the Account Balance DWH files.
In case of a positive balance write-off, the write-off is done through a support ticket to Enfuce. Enfuce specialists will ensure that the write-off is done correctly.
Enfuce provides 4 different balance write-off transaction types (BWO1, BWO2, BWO3, BWO4), which the issuer can use to segregate the write-off reasons in their reporting. As the balances are written off, they are posted to specific Write-off GL accounts, which will allow the issuer to have the necessary data for bookkeeping. For regulatory reporting, more details can be added to the transaction’s text section, which will be then reflected in the DWH reports and can also be queried via transaction API. For example, in case only one transaction needs to be written off, the transaction ID can be inserted into the text section of the write-off.