Using the Payment Adjustment (PYAJ) screen 103-04040080

Select from the below

• The refund of over-recovered debts via PYAJ (reason OVO) is limited to Payment Assurance Operations Debt Staff only. See Investigating a Refund of debt repayments

• If a partial family assistance payment has been returned from the financial institution, and the customer is entitled to the payment, see Returned payments and their effect on family assistance reconciliation before proceeding

• Check the coding of the previous activity to see why the customer was not paid the correct rate
• Correct the information to pay customer their correct rate. See Using the Review of Assessment (ROA) screen for more details regarding the payment of arrears
• System issues must be reported to the appropriate business team before paying via PYAJ
• System limitations (that is, where payments cannot be automatically issued for periods before the system limiting date) do not need to be reported, but care should be taken to ensure the coding is correct and not the cause of the limitation

• Where a payment cannot be paid via PYAJ (that is, an error presents), a Notice to prepare a Refund Account (SF030) form must be completed and sent to Financial Shared Services for action

Has the customer been paid what they are entitled?

• Yes, advise customer of the arrears owed and record details on a DOC. Procedure ends here
• No, and:
• the payment type is Child Care Subsidy, see Reissue a payment at a customer's request
• the customer is now deceased, see Replacing payment made to a deceased customer where payment was returned from financial institution
• all other customers, go to Step 3

Check:

• the customer is still eligible
• if the customer has made a lump sum repayment of their advance payment that has not updated in time resulting in further regular repayments occurring
• if there is a system issue preventing the payment of the correct rate. System issues must be reported to the relevant business team via mySupport. Advice will then be provided advising if the payment is to be paid by PYAJ. Check Notes/DOCs to confirm if workaround advice has already been provided. To report a system issue, see the Resources page for a list of relevant mySupport forms

Can payment be paid via PYAJ (that is, no error presents)?

• Yes, go to Step 5
• No, a Notice to prepare a Refund Account (SF030) form must be completed and sent to Financial Shared Services for action. Go to Step 4

If the relevant system does not allow PYAJ payment to be paid, a Notice to prepare a Refund Account (SF030) form must be completed and sent to Financial Shared Services for processing with all supporting documents/screens. See the Resources page for a link to the form.

• When sending the SF030, make sure to include:
• a copy of the DOC from the system detailing the need to refund payment
• any supporting documents
• any other relevant screens. Use the Snipping Tool to capture the screen shots and attach to the email
• Upload the completed SF030 to the customer’s record. Categorise as UNS005 – Financial, as a closed work item
• Record all details on a DOC, including:
• Confirmation that SF030 has been completed/sent to Financial Shared Services
• Payment Amount
• Entitlement/Date of original payment
• Reason SF030 has been completed
• Who the payment will be issued to
• Any relevant information that may help future interactions
• Delete the SF030 form from the secure drive

Procedure ends here.

• If a payment needs to be made by PYAJ but the Service Officer does not have access, the request must be escalated to the appropriate staff member
• Staff must follow normal escalation procedures to have this payment made. For service centre and smart centre staff, this is a staff member at the APS 5 level or above, for example, Service Support Officer. For smart centre staff, see Tier 0 technical support - self-sufficiency
• A DOC must be created detailing why the payment must be made via PYAJ

Go to the PYAJ screen in the relevant system. This will show the Payment Adjustment Warnings (PAWS) screen with the following information:

'Warning: Use of the PYAJ screen is monitored and you MUST document any payments issued using this screen.'

• Enter ‘S’ to view help
• Do not use this screen to do any of the following:
• issue a top-up payment when a customer changes their Entitlement Period End Date (EPED)
• reissue a returned Direct Credit payment
• issue arrears after review of a penalty
• make Bereavement Payments
• pay Farm Help Re-establishment Grant - this should only be paid through Essentials
• workaround system faults unless instructed by the ICT Service Desk
• Complete the Do you want to continue? (Y/N): field
• If after reading the warning the decision is made not to proceed, code N. Procedure ends here
• If the action does not involve any of the above, code Y. The PYAJ screen will show. Go to Step 7

Code the following fields:

Reason Code:

The values are as follows:

• REC (Reconciliation Discrepancy)
• SYL (System Limitation)
• AVR (Advance Payment Refund)

Reason codes for Debt Management Officers only:

• OVO (Over Recovered Repayments)
• RRF (repayment of a recovery fee component is refunded)
• ROI (repayment due to an interest charge to be refunded)

The coding of this field will not determine the delivery method of this payment. Payments will be made according to the payment delivery instructions which currently exist on the customer's Payment Destination (PA) screen.

To alter the payment method, reissue the payment via the Issue Future Payment (IFP) screen.

Service Reason (where required)

When directed to issue Flexible Support and Ex-gratia payments for Centrelink customers via the Payment Adjustment (PYAJ) screen, the Service Reason ‘TPA’ should be recorded. This will ensure the payment will not be rejected by the system.

Period Date (from & to):

This is the date from which the payment amount has been calculated. For arrears payments, it will be the date recorded for the payment on the Payment Details (PD) screen. If there is continuous entitlement for the whole period, payments can be entered as one activity. If there is no continuous entitlement, separate activities should be coded for each payment within the entitlement period.

The date keyed can be entered in any of the standard formats (1/1/99, 010199, 01 Jan 1999 or 1.1.99) but cannot be a date in the future. The date in the Period Date: field must be earlier or equal to the date in the to: field.

Component:

Each component of the payment must be coded separately. Up to 5 components may be coded in a single activity.

Net Amount: $ field will be automatically calculated by the system.

This is the net amount of the payment to be issued. Any deductions should not be included as part of this payment. Amounts must be in dollars and cents. The amount must be greater than $1.

If issuing a payment the following fields must be coded on this screen:

• Reason Code:
• Period Date: and to: fields
• Component:
• Amount: $

If there is no continuous entitlement, separate activities should be coded for each amount to be paid within the entitlement period.

Press [Enter] to continue

Payments made using the code AVR will not be included as income received from the department, as they are purely a refund of payments.

The system will show the PYAJC screen.

Confirm that the details of the payment are correct, then in the Submit? (Y/N/Q): field, enter 'Y', 'N' or 'Q'.

The Assessment Results (AR) screen should be carefully checked before finalising any activity.

Annotate DOC to confirm payment has been made.