Business Blueprint Document

Banking and Cash Management

6/09/2022 1 of 56
 Document Information and Revision History

Title Banking and Cash Management Blueprint

Document Purpose Definition of the SAP Banking and Cash Management modules
SAP Consultant
Business Owner

Version No Issue Date Author(s) Nature of Amendment

Blueprint Sign off

Resource Title Date Comments Signature

6/09/2022 2 of 56
 Table of Contents

1. Business Process Description..................................................................................5

1.1. Business Process Context.............................................................................5
1.2. Business Process Overview (Scope and Background).....................................5
1.3. Business Process Flow Description................................................................5
1.3.1. Bank Master Data..................................................................................5
1.3.2. House Banks.........................................................................................6
1.3.3. Bank Accounts.......................................................................................7
1.3.4. Bank Statement Upload.........................................................................8
1.3.5. Payment Process.................................................................................11
1.3.5.1. Manual Payment Process................................................................11
1.3.5.2. Automatic Payment Run Process....................................................12
1.3.6. Cash Forecasting and Liquidity Management.........................................14
1.3.7. Cash Forecasting memo records...........................................................15
1.3.8. Exchange Rates...................................................................................16
1.3.9. Forward Cover.....................................................................................16
1.3.10. Bank Guarantees.................................................................................18
1.3.11. Bank Bills............................................................................................19
1.3.12. POS Reconciliations..............................................................................20
2. Implementation....................................................................................................23
2.1. Organisation Structure...............................................................................23
2.2. Interfaces.................................................................................................23
2.3. Reporting Requirements.............................................................................23
2.4. Output Requirements.................................................................................23
2.5. Functional Enhancements...........................................................................23
2.6. Authorisations...........................................................................................24
3. Master Data Requirements....................................................................................25
3.1. Master Data Maintenance...........................................................................25
3.2. Master Data Conversion.............................................................................25
4. Appendices..........................................................................................................26
4.1. Appendix 1 - Bank Clearing Accounts..........................................................26
4.2. Appendix 2 - Planning Levels......................................................................27

6/09/2022 3 of 56
 4.3. Appendix 3 - Planning Groups....................................................................29
4.4. Appendix 4 - Planning Types......................................................................30
4.5. Appendix 5 - Memo Record Upload.............................................................31
4.6. Appendix 6 - ANZ Statement Format (Incoming).........................................33
4.7. Appendix 7 - ANZ Bank Account Information Codes and Descriptions............37
4.8. Appendix 8 - ANZ file format example.........................................................50
4.9. Appendix 9 - Proposed Structure of Bank Accounts and Clearing Accounts...51

6/09/2022 4 of 56
 1.

2. Business Process Description

3. Business Process Context
Banking functions in SAP represent the maintenance of master data and transactions to support Banking
Reconciliations and Cash Management/Forecasting for XXX.

4. Business Process Overview (Scope and Background)

The Banking application component provides functions to effectively manage business partners bank details
and company bank accounts. Bank master records represent the details of physical banks and branches in
SAP with whom XXX undertakes banking transactions.

Bank master data is used in business partner master data for payment transactions.

The Automatic payment program will manage all the payment transactions made by banks in SAP using
defined payment methods.

5. Business Process Flow Description

6. Bank Master Data

Within the bank sub module of SAP, the bank master data is saved centrally in the bank directory. Each bank
is uniquely identified by the country code and bank key (BSB identifier). Bank master data includes address
information and control data such as SWIFT code (used for overseas payment).

The following transactions can be performed on banking master data.

 Create
 Change
 Display
 Mark for deletion

Bank details maintained in the bank directory will be used for business partner master data and house
banks. This will eliminate duplication of data and keep up-to-date information of bank details.

To be able to run the payment program, the system requires details of XXX’s own house banks. In the
company code-specific data of a vendor master record, entry of house bank details is needed to facilitate
vendor payments. If a bank is not entered in the master record, the rules by which the payment program
determines the appropriate payment bank account must be specified.

At XXX, the house bank will be pre-defined and configured for the payment program.

6/09/2022 5 of 56
7. House Banks

Banks used by XXX to complete transactions are defined as house banks. House banks are created in
Customizing. House banks contain information such as bank master data, data for electronic payments, the
bank accounts for each house bank and the G/L accounts per bank account.

Using the House Bank ID and the bank types, the payment program determine the banks to be used.

Bank accounts that are managed by house banks are also defined in configuration. The accounts are
identified by a unique account-ID. The bank account data contains the number of the account at the house
bank, the account currency and the G/L account which reflects postings made to the bank statement
account.

For every bank account, a General Ledger account must be created. This General Ledger account is assigned
to the bank account and vice versa. Both accounts have to have the same account currency.

The House Bank is defined at the company code level. For XXX house banks will only be created for XXX Pty
Ltd company code (i.e. 1000). House bank “ANZ1” and “ANZ2” will be defined. The following settings will be
created in SAP:

House Bank ANZ1 ANZ2

Description Cash Operations Dividend Account

Bank Country AU AU

Bank Key

Telephone

Bank Name ANZ Banking ANZ Banking Corporation

Corporation

Street

City

Bank Branch

SWIFT code

Bank group

6/09/2022 6 of 56
8. Bank Accounts

For each House Bank, the user will need to maintain a Bank Account Identifier. The Bank Account Identifier
denotes the bank account that the company has with the respective House Bank. It contains information
about the bank account number, currency key and additional country-specific data.

Each bank account is unique within a company code. Under each bank account, the user will maintain the
bank key, bank country, addresses etc. The system uses this information to identify the correct bank master
data.

The following settings will be created in SAP:

House Bank ANZ1 ANZ1 ANZ1 ANZ1 ANZ2

Bank Key

Account ID AUD01 USD01 GBP01 EUR01 DIV01

Description XXX - Daily XXX - Overseas – XXX - Overseas – XXX - Overseas – XXX –
Bank Account USD GBP EUR Dividend
Account

Bank Account
Number

Currency AUD USD GBP EUR AUD

SWIFT number

General Ledger 101000 103000 104000 105000 102000

Account

Direct Entry ID

Manual Preparation Maintain House Bank Maintain Bank

And Approval ID Account ID
Use In
Payment End
Finance Finance Finance Run?

Yes
Auto Payment Run
Configuration

Finance

6/09/2022 7 of 56
The flowchart above documents the house bank / bank account maintenance process. This has the following
steps:

 Manual preparation and approval. This involves completing a manual form for the maintenance of
existing house bank/ bank account or to create new house bank/bank account. For a new house
bank/ bank account new general ledger accounts (i.e. bank statement account and bank clearing
accounts) would be identified and created within this step.
 Within SAP transaction FI11 is used to create a new House Bank – if required.
 Within SAP transaction FI11 is used to create a new Bank Account or transaction FI12 to amend an
existing Bank account
 If the new bank account is required for the Accounts Payable payment run – Additional configuration
is required for the bank determination and existing payment methods (Transaction FBZP)
 If the new bank account is not required for the Accounts Payable payment run – no further
configuration is required

The payment program needs to be configured to support payments from the relevant House Bank and house
bank IDs. The settings involve:
 Ranking order of banks:
 House banks are ranked according to the priority they should be used by the automatic
payment program.
 For XXX, house bank “ANZ1” will be ranked as “1”, as XXX has one house bank.
 Bank accounts:

 For each house bank the payment method and currency determine which bank account is to
be used for payments.
 For XXX, each bank account will be ranked as “1”, as XXX has one bank account for each of
the following currencies AUD, USD, EUR, and GBP.
 Available amounts:

 The available payment amount for the selected house bank. Specifying available amounts
enables the user to control which bank account is to be used for payments.
 For XXX, the maximum payment amount will be set to $40 million. The minimum payment
amount will be set to $1.00.

9. Bank Statement Upload

The electronic bank statement is a text file received from the bank for the purposes of automating the bank
reconciliation process. The electronic bank account statement file contains:

 Information on the house bank (bank number and account number, account currency,
statement number, and statement date)

 List of individual business transactions that were posted to the bank account (line items and
amounts)
Processing of the electronic bank statement is done at company code level and takes place in three stages.
 Each file is transferred (in the relevant account statement format) to the bank data storage.
 Data (i.e. Notes to Payee) are interpreted to derive clearing information from unstructured
information. This clearing information is stored in bank data storage.
 Postings are made online using the online indicator on the upload program
 Post processing is undertaken for tany transactions posting in error.

To ensure statements are posted properly, certain requirements must be fulfilled.

6/09/2022 8 of 56
  An internal posting rule must be defined for all posting transactions. This posting rule
represents the business transactions relevant to account statement entry and controls
postings to G/L and sub ledger accounts. The Internal Posting rule will post to the SAP
ledger. Clearing will occur once the bank statement has been posted to the ledger.
 For XXX, internal posting rules must be defined to enable the system to post to the
following bank clearing accounts:
o Store Deposits - Cash
o Store Deposits - EFTPOS
o Store Deposits - Cheques
o Other Deposits
o Cheque clearing
o Payments
 The following clearing accounts will apply for the transactions of the USD, GBP and EUR
bank accounts. Please note that these general ledger accounts will be set up in USD, GBP,
and EUR respectively.
o Payments
o Deposits
 External transactions must be defined to distinguish banking transactions (i.e. business
transaction code, text key, posting text) used by each bank. The list of external
transactions is described in Appendix 6 ANZ Bank Statement File format.
 External transactions must be assigned to a posting rule.
If, during data import, the program encounters an "unknown" external business transaction code, a list of
missing entries is output after the entire account statement is imported. These are processed as exceptions
using bank statement post-processing (i.e. SAP transaction FEBA).
Where possible, items appearing on the bank statement will be automated to post to the correct accounts.
Examples include bank charges, interest earned, interest paid and subscription fees. This will require
configuring default cost centres for items posting into revenue or cost accounts. Refer Controlling Blueprint.

The technical details for the file format of the bank interface are described in the appendices. Note the file
format provided by ANZ is SAP compliant (i.e. Multicash format).
The transaction identification codes have been sourced from the bank. These are the key to deriving the
SAP general ledger postings and forms part of the configuration.

Analysis of the supplied ANZ bank transaction codes has identified a need for a bank statement conversion
program. This program will use Bank transaction codes and note to payee descriptions to produce derived
transaction codes. These codes are in turn mapped to the respective SAP posting rules.
Refer to Appendix 6 ANZ Bank Statement File format.

The automatic clearing program will be set up to clear items in the various bank clearing accounts. This can
be scheduled as a daily job or executed manually as part of the bank reconciliation process. At XXX the
proposed clearing criteria are:
 Store Number (mapped to Profit Centre)
 Dollar Value (+/- $20 tolerance)
 Banking Type e.g. EFTPOS, cash / cheque, EFTPOS Refund (same G/L as EFTPOS)

Note that Value Date is not being used for POS reconciliations and is no longer applicable as a clearing
criteria for the Bank Statement.

6/09/2022 9 of 56
These are not standard settings and will be configured and tested within SAP. It is assumed the converted
bank statement file will provide enough detail for the automatic clearing program to operate correctly.

For XXX the following has been agreed:

 The SAP electronic bank reconciliation will be performed for company code “XXX”.

 The bank involved will be ANZ Bank. The interface will be from Bank to SAP on a daily basis for
the following bank accounts: AUD, USD, EUR, and GBP.

 The dividend bank account is not required to be processed using the electronic bank statement

 The standard SAP bank reports, bank statements, and logs will be used.

 The SAP electronic bank reconciliation will be performed daily by XXX.

Manual Clearing of Bank Clearing Accounts

If the automatic clearing program fails to clear items in the bank clearing accounts (due to missing
references or large differences etc), the clearing accounts can be manually cleared using transaction: Clear
G/L account (F-03).

Where there are differences between the total debit and credit amounts, the differences can be manually
charged off to a general ledger account. XXX requires a limit be placed on the amount that can be manually
written off – based on different users. This can be achieved by nominating an “amount per document” for a
tolerance group and assign the user to the tolerance group. ‘

In this case, the system will issue an error message if the amount to be written off exceeds the “amount per
document” as specified in the tolerance group. These settings should apply to manual clearing of these
items and not affect other transactions the user will be performing e.g. journal entries.

One tolerance group of zero tolerance (Z000) will be created. This tolerance group will need to be assigned
to the user.

During the build phase of the project, XXX will need to provide the project team with a list of the users to be
assigned to the tolerance groups. Once again, these tolerance groups need to be limited to manual clearing
of these banking items only.

6/09/2022 10 of 56
10. Payment Process

Outgoing payments to vendors can be done by manual payment and automatic payment run. The diagram
below shows both the payment processes.

Manual Invoice Post Payment

Selection and Doc Without print form
Preparation (F-53) Manual
Option 1
Cheques
Finance Finance To Be Written

Manual
Payment
Process
Manual Invoice Post Payment
Selection and Doc With print form System
Preparation (F-58) Automatically
Generate
Option 2
Finance Finance Cheques

Manual Payment Process Flow

10.1.1.1. Manual Payment Process

When executing the manual payment process, the user can determine whether to process the outgoing
payment with or without printouts such as cheque.

Before a payment is done in the system, the accounting staff will go through a series of manual preparations
such as determining which vendors to pay, analysing invoices which are due and seek approval from the
relevant accounting personnel for payment.

As an alternative, accounting staff can utilise the system to list invoices due for payment and commence
with manual payment preparation and subsequent approvals.

Upon the completion of the approval process, the accounting staff separates payments requiring printed
cheques and payments not requiring print output such as cash payments, manual cheques, electronic
transfer etc.

Payments requiring cheques can be posted via transaction code F-58. Payments without forms can be
posted via transaction F-53.

When performing a manual payment, cash discounts can be posted by entering the discount rates. Partial
payments can be performed using the “partial payment” or “residual payment” transactions.

Where a “partial payment” is processed, selected open items for payment are not cleared. The partial
payment is posted to the vendor account with an invoice reference. This enables the user to link the invoice
to the partial payment at any time.

When posting the payment as a residual item, the original payable (i.e. open item) is cleared automatically.

The cheques will be printed or manually prepared as required and sent to vendors.

6/09/2022 11 of 56
XXX will not be using the manual payment process.

10.1.1.2. Automatic Payment Run Process

Maintain Payment Generate Payment

Automatic Run Parameter Proposal
Payment
Process
Finance Finance
Edit Payment
Proposal

Review Payment Finance

Proposal

Finance Manual Approval For

Payment

Review Payment List Generate Payment Finance

System Run
automatically
Generate
Cheques Finance Finance Edit Payment
Proposal

Finance

Automatic Payment Run Process

Maintain Payment Run Parameters

In order to execute an automatic payment run, the user must first maintain the payment parameters. The
payment parameters define when, for which period, which company code, and which business partners
should be considered for payment by the payment program.

There is one payment medium program for each payment method. The payment media program will print
the payment forms or creates the data media for subsequent download as configured.

Generate Payment Proposal

Once the payment parameters have been maintained the user can execute the payment program to create
the payment proposal. The proposal will display those open items that are due for payments.

The payment program identifies the open items and selects the items to be paid. Items are paid as late as
possible without losing cash discount. The selection of open items for payment is based on several factors:

 Due date of the item. The Due Date is determined using the baseline date and the terms of payment
in the open items. The payment program calculates the cash discount periods and the due date for net
payment.

6/09/2022 12 of 56
 Company code-specific grace periods for payables. The grace period is added to the due date
calculated. Consequently, the payment can be made at a later date. At XXX, the grace period will be set
to zero.

 The minimum cash discount percentage rate per company code. If the specified minimum
percentage rate is not achieved, the system will propose the payment on the due date for net payment.

 Whether special G/L transactions are specified to be taken into consideration. For instance, the
payment program can make a down payment in response to a down payment request or specify if the
system wants to use the payment program to clear down payments. For XXX, the payment program will
be enabled to make a down payment as delivered in the XXX template. XXX will not be using Down
Payment functionality.

 For each payment run, the user will also specify the date of the next payment run on the payment
parameter. The program uses this date to determine whether an item is to be included in the current or
the next payment run.

Review Payment Proposal

User can view the proposal online or print it out as hard copy. It contains a complete overview of all line
items. The end of the list contains a breakdown of the payment amounts sorted by:

 Countries

 Currencies

 Payment Methods

 Banks

Edit Payment Proposal

The payments to be processed are displayed by vendor. Drill down functionality allows the payment line item
to be displayed. The user is able to edit the vendor payment line item by:

 Changing the Payment method

 Changing House bank/ bank accounts to be paid

 Changing Due date

 Changing Cash discount amount

 Block or unblock the payment line item

 Assign the line item to another payment

All changes made on the payment proposal affect only the payment proposal. No changes are made to the
source documents.

Generate Payment Run

Once the proposal has been finalised and accepted, the user will execute the payment. During the payment
run, the bank balance is reduced and vendor open line items are cleared as per proposal. That is:

6/09/2022 13 of 56
  The payment program creates payment accounting documents and prepares data for form printing
or creating file output.
 Payments will be posted to Payment Clearing (EFT) and Cheque Clearing (Unpresented Cheques).

Review Payment List

Prior to printing the payment cheques, the users should view the payment log and check over the payment
list to make sure that the payment run was completed successfully.

Generate Forms/ Payment Media.

Various payment medium programs use the data prepared by the payment program to create forms or files
for the data media.
Spool files are created within SAP allowing once the payments are confirmed, to print cheques and on-send
to suppliers.

11. Cash Forecasting and Liquidity Management

XXX will use the SAP Cash Management module. This module uses information from the Retail, Accounting
and Real Estate modules to generate the Cash Management and Liquidity Forecast reports.

The Cash Management report outlines the short term cash position using transactional information in the
bank statement and bank clearing accounts. This report is used to identify on a daily basis projected cash
surpluses and deficits. Based on this report decisions regarding investments of projected cash surpluses in
bank bills or sourcing loans to offset projected deficits can be made on a daily basis.

The process involves the following steps:

No Description Role Enablers Notes

1 Receive electronic bank Accountant ANZ Online

statement download

2 Execute electronic bank Accountant SE38

statement conversion
program

3 Upload electronic bank Accountant FF_5

statement into SAP

4 Post process banking Accountant FEBA

transactions in error

5 Confirm general ledger Accounts FF-6/ FS10 When the bank statement general
bank statement Receivable ledger account balances to the
reconciles to bank bank statement balance this
statement closing balance confirms that the opening
cashbook balance is correct. This
is a critical component to the cash
forecasting process.

6/09/2022 14 of 56
 No Description Role Enablers Notes

6 Enter Cash forecast Banking FF63/ Memo records can be entered

memo records for Equity manually or uploaded from an
Raised; Bills drawn; RFTS6510 excel spreadsheet.
Security Deposits;
Customs; Dividend
Payments; Forward
contracts taken; Forward
contracts repaid; Bills
Repaid;

7 Execute Cash Banking FF7A Cash Management report is

management report executed to outline daily and
short term cash position

8 Enter Cash forecast Banking FF63/ Memo records can be entered

memo records for manually or uploaded from an
Budgeted Daily Sales; RFTS6510 excel spreadsheet.
Lease incentives; Sales
and Leaseback

9 Execute Liquidity forecast Banking FF7B Liquidity forecast report is

report executed to outline short to mid
term cash position. This includes
information from Accounts
payable sub-ledger;

12. Cash Forecasting memo records

Within SAP manual entries can be entered into SAP Cash forecasting using memo records. This can be
entered manually via transaction FF63 or uploaded from a pre-defined excel format via transaction
RFTS6510.

Memo records would be created for the following cash forecast transactions:

 Budgeted Daily sales

 Commercial bills Drawn
 Loan revenue
 Rent received
 Seasonal bills Drawn
 Funds deposited
 Funds borrowed
 Security revenue
 Lease incentives
 Sales & leaseback
 Equity Raised
 Forward contracts taken
 Lease Payments
 Dividends
 Forward contracts Paid
 Seasonal bills Repaid
 Interest Paid

6/09/2022 15 of 56
 The above planning types are based on the existing cash management report presently used by XXX.

Within SAP planning types need to be configured for memo records. Details of the planning types to be
configured are outlined in Appendix 4.

6/09/2022 16 of 56
13. Exchange Rates

Exchange rates can be entered manually into SAP via transaction OB08.

The process would be to obtain the relevant exchange rates from the bank or internet site. These would be
compiled and entered into SAP using transaction OB08.

The following exchange rate types will be configured within SAP for XXX.

SAP Exchange Type of Exchange

Rate Type Rate Description Updated
F Average Average FEC rate (calculated by XXX) Weekly
P Planning Costing rate (assigned by XXX) As required
M Closing Daily spot rate (obtained from bank) Daily

The following currencies will be configured within SAP for XXX.

Currencies Name

AUD Australian Dollars

USD United States Dollars
GBP Great Britain Pounds
EUR Euro dollars

14. Forward Cover

XXX is a major importer of retail goods and can be exposed to adverse exchange rate movements. Forward
cover arrangements have been entered into with the ANZ bank to effectively “lock” in the Australian dollar
equivalent of future US dollar payments.

The process involves twice weekly assessing the number and amount of future USD, EUR or GBP payments
and arranging future USD, GBP or EUR funding through purchases in of the relevant currency using a
minimum amount fo $XXX.

XXX requires that forward cover arrangements are recorded in SAP and reported against future foreign
currency purchase payments.

The following process would be used to record and report forward cover arrangements:

 Foreign currency purchase orders are configured to report into SAP Cash Management.
 Cash forecast memo records have been configured as payment requests.
 Appropriate clearing accounts have been configured for bank-to-bank account transfers
 After electronic bank statements have been processed the Liquidity Forecast report is executed. A
report variant report foreign currency purchase orders; future foreign currency payments and also
forward cover arrangements already in place.
 Based on report XXX determines if more forward cover arrangements are required in either USD,
EUR or GBP currencies or whether existing arrangements are adequate.
 If more forward cover is required the ANZ Bank would be contacted to agree details of the amount;
funding date and the relevant forward exchange rate.

6/09/2022 17 of 56
  This would be recorded in SAP Banking/ Cash forecasting as a bank account transfer memo records
using transaction FF63. Details to be recorded in this transaction include:
o Company Code (Company Code XXX – i.e. 1000)
o Planning Type (ZF: Forward Cover based on Cash concentration planning memo)
o Value Date: (date of Future FX Cover Payment)
o Account Name: (Bank account funding payment i.e. XXX AUD Bank account)
o Amount (payment amount in USD, EUR or GBP as applicable)
o Currency (payment currency USD, EUR or GBP as applicable)
o Exchange Rate (amount of agreed exchange rate with bank)
o Assignment (details/id of FX cover transaction)
o Reference (transaction reference for forward cover transaction)
o Offsetting Account (Bank Account receiving payment i.e. XXX USD bank account, XXX EUR
bank account or XXX GBP bank account)
o Offset Value Date (Date of Future FX cover payment)
o Offset Company code (Company Code XXX – i.e. 1000)
o Payment Text (further details of FX cover payment)

Selecting the Account Transfer function automatically creates two payment advices one for the AUD
payment and another for the USD (or EUR, GBP as applicable) funding.

 Both payment requests are now visible in the Liquidity Forecast Report as a future forward cover
(i.e. USD deposit and AUD payment). Payment requests for EUR and GBP currencies are also visible.
 Transaction FF.D needs is executed to convert the AUD payment advice to a payment request. This
transaction should be run daily. No accounting entries are posted at this stage.
 Transaction F111 is a special payment run to handle payment requests. This would be executed
weekly to process Forward cover payment requests and post the following accounting entries:

DR Bank-to-Bank Transfer clearing.

CR ANZ Daily account - payments

 When the forward cover AUD payment is processed this is automatically posted from the electronic
bank statement as follows

DR ANZ Daily account - payments

CR ANZ Daily account

 Payment media would be processed to print details of the payment transfer for processing by ANZ.
 When the forward cover USD deposit is processed this is automatically posted from the electronic
bank statement as follows:

DR USD Daily account.

CR Bank to-Bank transfer clearing

 When the forward cover EUR deposit is processed this is automatically posted from the electronic
bank statement as follows

DR EUR Daily account.

CR Bank to-Bank transfer clearing

 When the forward cover GBP deposit is processed this is automatically posted from the electronic
bank statement as follows

6/09/2022 18 of 56
 DR GBP Daily account.

CR Bank to-Bank transfer clearing

6/09/2022 19 of 56
15. Bank Guarantees

As XXX is opening a store (or Distribution Centre) a landlord may request a Bank Guarantee to assure
payment of rental and property monies. XXX will request the ANZ Bank to arrange a bank guarantee for
particular landlord vendors .

XXX requires that bank guarantees be accounted for in SAP on a statistical basis. This allows guarantees to
be accounted for as contingent liabilites and can be listed as a note to the Balance Sheet.

Using the SAP Special General Ledger entries can be used to record Bank Guarantees given on behalf of XXX
by the ANZ Bank.

The proposed process is as follows:

 Landlord requires that XXX provide a Bank Guarantee as part of a property agreement. This is done
as XXX opens a new store or new Distribution Centre.
 ANZ Bank is contacted to arrange the bank guarantee with the vendor on behalf of XXX.
 The bank guarantee given is recorded as a statistical posting (transaction F-55). The following
information is entered:
o Document Date
o Posting date
o Company code
o Reference
o Posting Key
o Vendor account (this would be the Landlord requiring the bank guarantee)
o Guarantee amount
o Due Date: Guarantee Due Date
o Assignment
o Special G/L assignment: guarantee number/ reference
o Text: description of guarantee – noting that the ANZ bank is giving the bank guarantee.
 The following general ledger postings are generated:
DR Guarantees Clearing
CR Guarantees - Vendors
 In balance sheet reporting this transaction is offset by an automated entry to Guarantees clearing –
resulting in a nil effect on balance sheet reporting.
 Using SAP transaction FB02– Word or other documents can be attached to the accounting document
 To view a guarantee use the document display transaction FB03 using the document number
generated from the statistical posting.
 To view the bank guarantee via vendor use the vendor display line items transaction (i.e. FBL1N).
Ensure that the Special G/L transaction criteria are checked.
 To view all bank guarantees use the G/L account display line items transaction (i.e. FBL3N). Ensure
that the Normal item type is checked.
 To reverse a guarantee the reversal statistical posting transaction is used i.e. SAP transaction F-56.
The following information is entered:
o Document Date
o Posting date
o Company code
o Guarantee Received General Ledger account

Then Select the appropriate guarantee to be reversed. Post the document

 The following general ledger postings are generated:

6/09/2022 20 of 56
 DR Guarantees - Vendors
CR Guarantees Clearing

6/09/2022 21 of 56
16. Bank Bills

On a periodic basis XXX will use discounted bank bills to supplement existing cash funds. These transactions
need to be recorded in the SAP General Ledger and be included on the Cash Management/ Liquidity Forecast
report.

The following process is proposed for bank bills:

 After electronic bank statements have been processed the Liquidity Forecast report is executed. This
report will identify potential cash surpluses and cash deficits of AUD Cash for XXX.
 Based on the information in this report XXX would determine if discounted bank bills are to be
funded via the ANZ Bank or other parties.
 If bank bills are required to be funded the ANZ Bank or other party would be contacted to agree
details of the amount; discount rate and the relevant rollover date.
 This would be recorded in SAP General Ledger using the following journal entries:

DR ANZ Daily account – Other Deposits

DR Prepaid Interest

CR Bank Bills

When the bank bill funding transaction is processed through the bank statement an offsetting entry
would be made to the deposit clearing account

DR ANZ Daily account

CR ANZ Daily account – Other Deposits

 In terms of the rollover entries forward dated journals would be entered with a balancing entry to be
made to the bank payment clearing account:

DR Bank Bills

CR ANZ Daily account -payments

 The forward dated journals enable the future bill rollover transaction to be reported in the cash
management/ liquidity forecast report.
 When the bank bill rollover is processed through the bank statement an offsetting entry would be
made to the payment clearing account.

DR ANZ Daily account -payments

CR ANZ Daily account

6/09/2022 22 of 56
17. POS Reconciliations

Referring to the blueprint for POS interfaces the following POS GL journal entries are initiated during
the Store End of Day process:

 Aggregated sales (idocs WPUUMS and WPUTAB):

DR POS Clearing

CR Sales

CR GST

Sales entries are aggregated by store/article/day and posted by store profit centre.

POS clearing entries are aggregated by store/tender/day and posted by store profit centre.

 End of day Store posting (iDocs WPUFIB)

DR Cash – Receivables

DR EFTPOS – Receivables

CR POS Clearing Account

Balances in the POS clearing relate to articles processed by POS which do not exist in SAP.

Daily tender totals are aggregated by store/tender type/day and posted by store profit centre.

 Individual GL Postings by store/day(iDocs WPUFIB)

For actual cash counted in store (recorded in Surefire)

DR Cash (at Store)

DR Floats

DR POS Variances

CR Cash – Receivables

Actual cash counted entries are posted by day, by posting date and store profit centre.

For actual cash sent to bank (recorded in Surefire interfaced using iDoc WPUFIB)

DR Cash (at Bank)

CR Cash (at Store)

Actual cash sent to the bank entries are posted by day and store profit centre.

6/09/2022 23 of 56
  Electronic Bank Reconciliation entries

The SAP electronic bank statement will generate the following entries for actual EFTPOS and
store deposits banked:

DR Bank

DR Banking variances

CR Cash (at Bank)

CR POS Receivables

These entries will be posted by store profit centre; POS machine Id; value date and posting
date.

This process results in the following accounts requiring reconciliations:

 POS Clearing account: This account is posted by the store end of day process. Debit entries
to this account are sourced from the POS billing documents. The account is subsequently
cleared by the Store End of day payment document (by tender) process. A debit or credit
balance in this account at end of day reflects errors between the sales totals and the tender
totals i.e. Cash and EFTPOS.

This account is to be reconciled by store profit centre and posting date.

 Cash Receivables This account is posted to by the store end of day process. The balance of
this account reflects the daily total of cash tender for a particular store. Postings to this
account are by store profit centre.

This account is to be reconciled by store profit centre and posting date.

 EFTPOS Receivables: This account is posted to by the store end of day process. The balance
in the account represents EFTPOS tender receivable from the bank. EFTPOS bank deposits
by POS machine Id are posted to this account by store profit centre by the electronic bank
statement. The store profit centre will be derived via the bank statement conversion
program using the EFTPOS machine identification code on the bank statement.

This account is to be reconciled by store profit centre and posting date. Note that there will
be reconciling differences for stores which engage in 24 hour trading or trading past the 9
pm AEST EFTPOS cut-off time.

 Cash at Store: This account is posted to by the store end of day process and the balance
represents the cash held at the store not yet banked or cleared. Balances in this account are
held by store profit centre.

This account is to be reconciled by store profit centre and posting date.

 Cash at Bank: This account is posted to in the store end of day process and also by the
electronic bank statement. A Debit balance represents cash that has been cleared from the
store but not yet deposited to the bank. Balances in this account are held by store profit
centre.

6/09/2022 24 of 56
 This account is to be reconciled by store profit centre and posting date.

Specific scenarios:

 24 hour trading/ EFTPOS Cut-offs. XXX have several stores (up to 4) which will have extended
trading hours twice a year. These stores are processing sales past the bank EFTPOS cut-off time of
9 pm. In this case Sales processed past the EFTPOS cut-off date are not included in the EFTPOS
deposits for the current working day. These sales are included in the next working day’s deposits.

EFTPOS cut-offs are recognised where there are differences between the amounts posted to the
EFTPOS receivables account by the POS end of day process and the electronic bank statement.
These differences will offset against each other on a daily basis. POS DM analysatics will be used to
identify the amount of these differences.

The EFTPOS receivable amounts would be posted by store profit centre.

 Forced End of Day closure. This is the scenario where the automated XXX end of day store POS
closure has failed. The closure is delayed for a second day after which the process fails. A manual
closure is initiated which creates a file containing up to three days of transactions.

The End of Day POS interface will post store transactions based on the sales transaction date i.e. by
store by tender by day.

It is understood that the Surefire POS system has the capability to produce separate files for each
day during a forced end of day closure. It is highly recommended that this functionality be
implemented in Surefire if not already.

6/09/2022 25 of 56
 18. Implementation
19. Organisation Structure

No impacts on organisational structure are expected.

20. Interfaces

The following interfaces are required.

 Bank statement upload

 Bank Directory Upload. This inserts and deletes bank information from the current file of bank
branches.

 Outgoing payments (refer Accounts Payable Blueprint)

21. Reporting Requirements

Standard SAP reports will be used to print a copy of bank statement from SAP. Accounts Payable reports will
be covered in the Accounts Payable Blueprint.

22. Output Requirements

Cheques - please refer to Accounts Payable Blueprint.

23. Functional Enhancements

The following functional enhancements are required:

 Bank statement conversion program that uses a combination of Bank transaction code and note to
payee description to derive a new Bank transaction code. This derived bank transaction code is
mapped to the appropriate posting rule using SAP standard configuration.

Note that POS deposits are received by POS machine ID. Logic will be implemented in the
conversion program to derive the appropriate store profit centre when posting POS banking
transactions. The logic will determine whether the POS machine is an existing POS machine which
uses the “old” XXX store code or a new POS machine using the new XXX store code. XXX will
implement a POS machine description to distinguish between existing and new POS machines. If an
existing machine the conversion program will identify the three digit store number and add the state
identifier (2,3, etc) to convert to a four digit SAP store number/profit centre. If a new machine the
conversion program will identify the four digit store number as a SAP profit Centre.

Bank statement document search functions will then be used to identify the store number and
automatically map to a SAP profit centre. This will facilitate the POS reconciliation process.

This enables POS receipts for different tender types to be reconciled as required.

Note that logic for the assignment of trading day assignments will be outlined in the POS interfaces
Blueprint

 Bank directory upload program. A file of bank branch details is obtained from Blue Star as a yearly
subscription. This file is uploaded into SAP via the bank directory upload program (available as a
XXX standard program). This file is obtained each quarterly and updated details loaded into SAP.

6/09/2022 26 of 56
 The uploaded file facilitates the automatic population of bank address and branch details upon entry
of the bank key.

24. Authorisations

A high level view of roles, functions and transactions will be compiled to determine if standard XXX roles and
authorisations are adequate to cover XXX’s security requirements.

6/09/2022 27 of 56
 25. Master Data Requirements
26. Master Data Maintenance
House banks “ANZ1” and “ANZ2” will be set up in the system initially. Vendors will require relevant bank
master data to be recorded to facilitate EFT outgoing payments.

27. Master Data Conversion

For the purpose of data conversion, XXX will load bank master data from a bank directory. This directory will
be sourced from an external supplier (Blue Star Print).

For the purpose of transaction conversion XXX will load as open items into SAP prior to go live details of:
 unpresented cheques;
 unpresented EFTs;
 unpresented Store Deposits,
 unpresented POS deposits.

Details of unpresented cheques will be loaded into the SAP cheque register.

The balance of the bank statement will equal the reconciled bank statement balance prior to the go live
date.

6/09/2022 28 of 56
28. Appendices
29. Appendix 1 - Bank Clearing Accounts

The structure of the bank clearing accounts is important for bank statement processing and also cash
management reporting/ forecasting.

Balances in the bank clearing accounts relate to transactions posted that remain uncleared such as cheques,
deposits, EFT payments, or POS receipts. Using a manual bank reconciliation procedure transactions need to
be checked with bank records to determine if the transaction is cleared or is a reconciling item. This process
is automated in SAP through the electronic bank statement upload, the automatic clearing programs and
through the structure of the bank clearing accounts.

Within the configuration of the electronic bank statement “masking” together with the bank General Ledger
account number is used to determine the relevant bank clearing account for postings. This requires that
bank clearing accounts have a consistent structure.

For example the bank statement general ledger account is 110000 and the Store EFTPOS clearings are
configured to post to a GL account ending with 6 (i.e. +++++6). The electronic banking program would
derive GL account 110006 and post the appropriate entries to this account.

The following bank clearing accounts are proposed for XXX:

 +++100 - Cheque Clearing (Unpresented Cheques).

 +++200 - Payment Clearing (EFT)
 +++300 - Store Deposits - Cash
 +++400 - Store Deposits – EFTPOS (note that the bank cannot split these amounts
between credit cards and debit cards)
 +++700 - Other Deposits Clearing

Note that a funding transfer account will be required as XXX transfers funds from one bank account to
another. For example funds are transferred from the main bank account to the USD currency account to
fund USD payment transactions.

The funding entries would be initiated by an AUD payment from AUD Bank account to the USD bank
account.
The bank statement would be configured to generate the following entries.
USD Bank account in USD currency
DR USD Bank account (for USD funding deposit)
CR Bank funds Transfer

AUD Bank account in AUD currency

DR Bank funds Transfer
CR Australian bank account (for AUD funding payment)

6/09/2022 29 of 56
30. Appendix 2 - Planning Levels

Planning levels are used toclassify different elements in the Cash Management/ Liquidity Forecast
Report. The following Planning Levels are based on the groupings used in XXX Weekly Cash
forecast report and are to be configured in the SAP Cash Forecasting module.

Planning Level Source Description

AB Bank Payment advice (confirmed)

AU Bank Payment advice (unconfirmed)

B1 Bank Cheque Payments

B2 Bank Domestic Payments

B3 Bank Foreign Payments

B4 Bank Bank collection

B5 Bank Other interim postings

B6 Bank Own-accepted liabilities

B7 Bank Commercial Bills Repaid

B8 Bank Incoming Deposits

B9 Bank Daily POS receipts

CB Bank Commercial bills Drawn

CL Bank Cash concentration

DE Bank Interest revenue

DI Bank General planning

DV Bank Dividend Payments

GS Bank GST Payments

F0 Bank Posting to bank account

IB Bank Interest Derivatives Bank

KB Bank Deposit at notice

LB Bank Bank loans

ME Bank Rent receipts

6/09/2022 30 of 56
Planning Level Source Description

MP Bank Noted items

SB Bank Seasonal bills Drawn

TA Bank Deposit/loan mgmt: invest

TB Bank Time deposits: banks

TD Bank Fixed-term deposit management

TK Bank Deposit/loan mgmt: borrow

WB Bank Bank securities

WP Bank Security revenue

ZB Bank All fields of bank records

X1 Bank Lease incentives

X2 Bank Sales & leaseback

X3 Bank Equity Raised

X4 Bank Forward contracts taken

Y1 Bank Lease Payments

Y2 Bank Dividends

Y3 Bank Forward contracts Paid

Y4 Bank Seasonal bills Repaid

Y5 Bank Interest Paid

M1 Logistics Purchase requisition

M2 Logistics Purchase order

M3 Logistics Scheduling agreement

S1 Logistics Sales Orders

DI Sub-Ledger General planning

F1 Sub-Ledger Posting of purchasing & sales

F2 Sub-Ledger

6/09/2022 31 of 56
Planning Level Source Description

FF Sub-Ledger Down payment request

FK Sub-Ledger Advance pymts (offsettg entry)

FW Sub-Ledger FI bill of exchange

MP Sub-Ledger Planning - Noted items

RE Sub-Ledger Real Estate

XA Sub-Ledger Blocked for payment

XR Sub-Ledger Invoice verification

XX Sub-Ledger Block indicator X

ZP Sub-Ledger All fields, subledger records

6/09/2022 32 of 56
31. Appendix 3 - Planning Groups

Planning levels are used to classify different vendors and customer in the Cash Management/ Liquidity
Forecast Report.

The following Planning Groups would be configured for XXX Cash Forecasting:

Planning Group Planning Level Description

A1 F1 Local Creditor payments
A2 F1 Overseas T/T payments
A3 F1 Vendor-affiliated companies
A4 F1 Major vendors
A5 F1 Wages
A6 F1 Income Tax/ FBT
A7 F1 CDM
A8 F1 Gluck
A9 F1 ERP
AA F1 Bonus
AB F1 On Costs
AC F1 Occupancy
AD F1 Capital Assets
E1 F2 Customer receipts (A/R)
E2 F2 Domestic customers
E3 F2 Foreign customers
E4 F2 Customer-affiliated companies
E5 F2 High risk customer
E6 F2 Major customers
E7 F2 Rent received
E8 F2 Loan redemption (A/R)

6/09/2022 33 of 56
32. Appendix 4 - Planning Types

Planning types are used to classify different Planning memo transactions in the Cash Management/ Liquidity
Forecast Report.

The following Planning Types would be configured for XXX Cash Forecasting.

Planning Type Planning Level Description

AB AB Confirmed Advices

AU AU Unconfirmed advices

B9 B9 Budgeted Daily sales

CB CB Commercial bills Drawn

CL CL Cash concentration

DE DE Loan revenue

DI DI General planning

DV DV Dividend Payments

ME ME Rent received

MP MP Noted items

SB SB Seasonal bills Drawn

TA TA Funds deposited

TD TD Fixed-term deposits

TK TK Funds borrowed

WP WP Security revenue

X1 X1 Lease incentives

X2 X2 Sales & leaseback

X3 X3 Equity Raised

X4 X4 Forward contracts taken (Must use same

configuration as Cash concentration)

Y1 Y1 Lease Payments

6/09/2022 34 of 56
Y2 Y2 Dividends

Y3 Y3 Forward contracts Paid

Y4 Y4 Seasonal bills Repaid

Y5 Y5 Interest Paid

ZB ZB All bank fields

ZP ZP All subledger fields

Note that Cash Management Bank Accounts need to be configured.

6/09/2022 35 of 56
33. Appendix 5 - Memo Record Upload

Within the Cash Management module manual adjustments can be recorded via memo records.

XXX wish to upload memo records for Cash forecasting from Microsoft Excel. This can be done using SAP
transaction RFTS6510. Memo records can be uploaded using the following formats i.e. XML; Excel, CSV;
tabbed text and text without separator formats.

Memo records would be used to record:

- Foreign currency forward purchases

- Bills transactions

- Bill rollover transactions

Uploaded memo records have the following file format.

Field Name Field Type Field Length Description Comments

Company Code Char 4 1000

G/L acct/
Internal Cash Mgmt

account Char 10

Planning group Char 2

Planning level Char 2

Planned currency Currency 5

Planning date Date 8

Business Area Char 4 Leave blank

Amount in local
currency Currency 15 2
Amount in planned
currency Currency 15 2

Exchange rate type Char 4

Indicator: inverted
rate entry Char 1

Planning type Char 2

User who created
the record Char 12 Optional
Record Creation
Date Date 8 Optional
Last user to
Change Record Char 12 Optional

6/09/2022 36 of 56
Field Name Field Type Field Length Description Comments

Date of last change Date 8 Optional

Automatic
expiration date Date 8

Characteristics Char 25 Optional

Assignment no Char 18 Optional

Ref.Rate Char 16 Optional

Text Char 50

Offsetting account Char 10 Optional

Offsetting company
code Char 4 Optional
Offsetting value
date Date 8 Optional
Bank statement
number Numeric 5 Optional
Bank statement
date Date 8 Optional

Transaction type Char 10 Optional

Interest rate Decimal 73 Optional

Calendar type Char 1 Optional

Statistics indicator Char 1 Optional

Start date Date 8 Optional

Payment advice ID Numeric 10 Optional

Pairing payment
advices Reason ind Char 1 Optional
Authorization and
Release Flag Char 8 Optional

Also refer to attached excel spreadsheet for further details:

6/09/2022 37 of 56
34. Appendix 6 - ANZ Statement Format (Incoming)

The files into which account information is downloaded are based on the Multicash electronic data
transmission standards. ANZ Online uses the Multicash format which is SAP compatible.

ANZ Bank files are comma delimited and do not contain fixed length fields. The format identifies the start
and end of the file being sent, the date, the account number and the type of each transaction.

File Naming Convention

File Name:
- yydddnnB.csv
- yydddnnT.csv

Where:
yy is the 2-digit year
ddd is the julian day of the date

E.g. 9900601B.csv Balance data for 6th Jan 1999

9900601T.csv Transaction data for 6th Jan 1999

7.3.2 File Format

SAPGen displays balance and transaction records separated by a semi-colon (;).

Creates 1 balance file and 1 transaction file per day on all accounts registered to the
same source.
E.g. CMM = 1 balance and 1 transaction file per day containing information for
1 or more accounts.
HFR = 1 balance and 1 transaction file per day containing information
for 1 or more accounts.
It is used for:
• ANZ OnLine

6/09/2022 38 of 56
6/09/2022 39 of 56
6/09/2022 40 of 56
6/09/2022 41 of 56
35. Appendix 7 - ANZ Bank Account Information Codes and Descriptions

Transactions are given a three-digit code that identifies the transaction type, and a description that is used
to give more information about the transaction. The table below outlines the Account summary codes.

6/09/2022 42 of 56
6/09/2022 43 of 56
6/09/2022 44 of 56
6/09/2022 45 of 56
6/09/2022 46 of 56
6/09/2022 47 of 56
6/09/2022 48 of 56
6/09/2022 49 of 56
6/09/2022 50 of 56
6/09/2022 51 of 56
6/09/2022 52 of 56
6/09/2022 53 of 56
6/09/2022 54 of 56
36. Appendix 8 - ANZ file format example

Awaiting ANZ Online Multicash file – to be provided during Realisation

6/09/2022 55 of 56
37. Appendix 9 - Proposed Structure of Bank Accounts and Clearing Accounts

Bank Account: Bank Clearing Account Description Cash Management Account

Account Name
100010 Cash on Hand - Local
100020 Cash on Hand - Foreign
100030 Register Floats
100040 Cash on Hand - Store
100050 Cash at Bank - Store
100060 POS Clearing - Store
100070 POS Variances - Store
100080 Bank variance
100090 Cash -Store Receivables
100100 EFTPOS -Store Receivables
101000 ANZ daily account ANZAUDMAIN
101100 ANZ daily account - cheque ANZAUDCHQ
clearing
101200 ANZ daily account - payments ANZAUDPAY
101300 ANZ daily account - store ANZAUDDEP1
deposits cash
101400 ANZ daily account - store ANZAUDDEP2
deposits POS
101600 ANZ daily account - store ANZAUDDEP3
deposits cheques
101700 ANZ daily account - other ANZAUDDEP4
deposits
102000 Dividend Account ANZDIVMAIN
102100 Dividend Account - payments ANZDIVPAYT
102700 Dividend Account - deposits ANZDIVDEP
103000 USD daily account ANZUSDMAIN
103100 USD daily account - payments ANZUSDPAYT
103700 USD daily account - deposits ANZUSDDEP
104000 GBP daily account ANZUSDMAIN
104100 GBP daily account - payments ANZUSDPAYT
104700 GBP daily account - deposits ANZUSDDEP
105000 EUR daily account ANZEURMAIN
105100 EUR daily account - payments ANZEURPAYT
105700 EUR daily account - deposits ANZEURDEP

6/09/2022 56 of 56