Request a Refund

Request a refund is a newly built form that enables citizens to request a refund and for this request to be passed automatically into the back office.

The form has the following functionality:

a) Automatic authentication of the customer (checking that their account number/surname match)

b) Automated retrieval of overall credit (i.e. if -100.00 in credit on this year but £10.00 in arrears on last year, it will show £90.00 credit payable)

c) Automatic retrieval of existing bank details to use for processing the refund request

d) The ability to request the money is paid into a different account

e) The ability to provide bank details if none were previously held on the account

f) It will present an error if there is no refund due

g) It will validate the bank account details entered using the best in class online bank validation provided by Loqate - part of GBG.

h) Upon submission it will push the refund request into the back office application (NEC is the only back office this is available for right now)

i) Upon submission it will pass a PDF of the refund request to your document management application

j) Upon submission it will send an email receipt

The following illustrates the form/questions.

As with all RPO forms the customer is authenticated as a part of the process. Below we can see that the authentication has failed and the customer is presented with the message: "We were unable to find a matching council tax account":

Note the wording of this (and virtually all wording) can be changed in the Resources area of eGovHub - forms system management:

Where the customer provides a valid council tax account they're address will be presented and they can continue:

We go on to capture a phone number, email address and where someone is completing the form on their behalf their details.

It is the next page of the form where intelligence is deployed to ensure only valid refunds are awarded.

We will show the various scenarios below but the important thing to note is the form is smart enough to look at the overall balance not simply whether a single year is in credit. I.e.

a) If one year is in credit and others are at £0.00 it knows this is a valid credit for the year (assuming benefit re-calculaton has already happened of course)

b) If one year is in credit and another is >0.00 it knows to offset these to derive the real credit and if there is no credit they will be told they're ineligible

c) If two years are in credit and and others are at £0.00, it knows to refund money back to the respective years.

The following are the various scenarios of functionality:

Scenario 1 - Person has a credit and a pre-existing bank account is held:

Scenario 2 - Person has a credit and a bank account is not currently held:

Scenario - Person is not eligible for a refund:

A message is presented and the customer is unable to submit the form.

Scenario - Person has provided invalid bank details

We can see the message presented and this prevents the form from being submitted until remedied: