Step-by-step Licensing


Workflow-based Returned Debit Processing

Returned debit processing takes place according to a standard workflow which has been derived from the experiences made by many retailers, but it can also be adjusted to your individual circumstances.



In practice, workflow is administrated through statuses: each back transfer in the system takes on a particular processing status (i. e. workflow step) from which it will proceed to a specified follow-up status on the basis of defined events (deadline expiration, incoming and outgoing correspondence, acquisition of owner’s address, receipt of payment).


Status progression and the events that lead to a status change can be defined largely according to customer needs. What is more, own statuses can be introduced in order to model specific workflow areas in detail, e. g. for evaluation or intermediate steps.


Below, we have illustrated the following possible workflow steps more explicitly:


  • trial run
  • receipt request and address acquisition
  • dunning and collection


If you have any question as to how the standard workflow can be adjusted to the individual procedures in your company, our service team will be glad to advise you. Please make use of our contact form to request further information.

Making Doubly Sure: The “Trial Run”

At this particular stage in the standard workflow, the so-called trial run takes effect. Its aim comprises claim redemption via a resubmission of the original debit (including fees if applicable) without ensuing costs from receipt request or address acquisition.

bc:pos trial run

Experiences gained by our customers show that with bc:pos over half of all returned debits are handled automatically because they receive payment via the trial run without the need for any manual tasks. This saves time, effort and costs – we will gladly figure out the extent of possible savings together with you.

Successful payment redemption largely depends on the point in time for resubmission which bc:pos determines automatically on the basis of data for common respite periods after which regularly recurring cash inflows (salary, wages, pensions) will have provided sufficient liquidity with high probability. If the second debit is returned as well, the system will register this and match the event to the original debit. In this way, it is ensured that the given case will proceed to receipt request, for instance, and a trial run repeat will not be triggered.

Receipt Request and Address Acquisition

As a next step, the payment receipt signed by the card owner is requested so as to be able to furnish the bank in charge of the account with evidence for the right to acquire the card owner’s address.

bc:pos receipt request

In most cases, a letter or fax to the branch will be necessary to retain the receipt. Retailers without branches or with a central receipt deposit will skip the letter and retrieve the receipt directly.

During receipt request and address acquisition, manual tasks are unavoidable: the receipt must be located, copied and attached to the bank letter. The answer by the bank or a commercial address provider, i. e. the address, needs to be entered.

bc:pos will, however, undertake all other steps automatically, for example deadline monitoring and further measures after deadline expiration. If the receipt is missing, the corresponding returned debits will be set to ‘end status’. This status denotes that further processing is impossible and why (for statistical assessment purposes). If the waiting period for an answer from the bank expires, a new letter to the bank can be composed.

Usually banks charge fees for address provisions which can be administrated as external fees in bc:pos for all banks registered in bc:pos. These fees can then be added to the total amount of a returned debit automatically.



Dunning and Collection

As soon as all necessary data is available in bc:pos, customer letters (payment reminders/demands) can be composed.

Necessary data include:


  • overview on all outstanding claims (generated by bc:pos)
  • address (from in-house database, bank or address provider)
  • report on any internal and external fees accrued

bc:pos dunningbc:pos thus provides complete and automatic dunning procedures which


  • monitor all deadlines
  • generate the respective next dunning letter
  • print out all letters automatically on the basis of templates
  • calculate and display applicable fees


This functionality leads to a significant economization in debtor management: only very rare cases of customers in default paying cash need to be entered manually. bc:pos takes care of everything else by itself.