Bank Accounting Business Blueprint
Bank Accounting Business Blueprint
Business Blueprint
Bank Accounting
Version 0.1
Prepared by Finance Team
06/05/2013
This document contains information that is proprietary and confidential to Australian Pharmaceutical Industries, which shall not be disclosed, transmitted, or duplicated, used in whole or in part for any
purpose other than its intended purpose outside Australian Pharmaceutical Industries. Any use or disclosure in whole or in part of this information without express written permission of Australian
Pharmaceutical Industries is prohibited. Any other company and product names mentioned are used for identification purposes only, and may be trademarks of their respective owners.
DOCUMENT CONTROL
Authors
Name Role Version Description Date
Poonam Gupta OneERP Finance Team 0.1 10.06.2013
Irene Chen OneERP Finance Process 0.1 10.06.2013
Specialist
David Vaughan OneERP Finance Lead 10.06.2013
Reviewers
Name Role Date
David Vaughan OneERP Finance Lead 17.06.2013
Craig Hawke OneERP Finance Process Lead
Steve Gutmann OneERP Solution Architect
Craig Wilkeson OneERP Solution Architect
Anne Howard OneERP Technical Lead
Approvers
Name Role Date
Craig Hawke OneERP Finance Process Lead
David Vaughan OneERP Finance Lead
Kevin Geary OneERP Project Manager
Cary Farmer OneERP Project Director
Graeme Fallet OneERP Finance Process Owner
Reference Documents
Title Version Location
OneERP Project Glossary
CONTENTS
1 Business Requirements 5
1.1 Purpose 5
1.2 Scope 5
1.3 Audience 6
1.4 Business Rules 6
2 Solution Design 9
2.1 Overview 9
2.1.1 Key Design Principles 9
2.1.2 Key Assumptions 9
2.5 Process Design – Bank Files for Customer and Vendor Payments 24
2.5.1 Description 24
2.5.2 Process Flow 24
2.5.3 Process Steps 25
2.5.4 Location 25
2.5.5 Frequency 25
2.5.6 Duration 25
2.5.7 User Interface 25
2.5.8 Process Variations 25
1 BUSINESS REQUIREMENTS
This document is the Business Blueprint for the Bank Accounting module of SAP. The Business Blueprint represents
the conceptual design of the system and will be the basis for the system’s development in the remaining phases of the
project.
1.1 PURPOSE
This Bank Accounting Business Blueprint Design (BBD) comprises the processes and procedure steps for creation of
House Banks and Bank Accounts, uploading of Bank Statements, perform Bank Reconciliations and reporting.
1.2 SCOPE
The document covers all processes relating to Bank Accounting 6.7 under area 6 Finance in the process scope below:
The below is a context diagram of ‘creation to reporting’ End to End business process.
End-to-End Process Overview
Figure
1:
House
Bank
Creation
to
Reportin
g
NB:
Level 1 =
High
Level
Process
e.g. Finance
Level 2 = Process level e.g. Fixed Assets, General Ledger, Bank Accounting
Level 3 = Sub Process level e.g. House Bank Creation, Electronic Bank Statement upload
During the Blueprint phase, the level 3 processes were determined (see table below).
Level 2 Level 3
6.7 Bank Accounting 6.7.2 House Bank Creation
6.7.3 Electronic Bank Statement Upload
6.7.4 Bank Reconciliation Process
6.7.5 Bank Files for Customer and Vendor Payments
The level 3 processes were analysed and decomposed into a number of level 4 process steps (documented in more detail
in Section 2 of this Blueprint).
1.3 AUDIENCE
This document will help:
Business Process Team
SMEs and Business Customers
Implementation team from TCS
Post Go Live Support team
Project Team
Criticality
ID Description Met by Design Reason not met
[H/M/L]
1 Must have the ability to create / maintain House H Yes
Banks and Accounts as required. Refer to Section
2.2.1
2 Must have the ability to create multiple bank H Yes
accounts within a house bank Refer to Section
2.2.1
3 Must have the ability to validate BSB and L Yes
account length to ensure accuracy of inputs Refer to Section
2.2.1
Criticality
ID Description Met by Design Reason not met
[H/M/L]
4 Must have the ability to segregate incoming / H Yes
outgoing bank transactions and account for them Refer to Section
correctly. (Posting rules for each transaction to be 2.3.1
specified)
5 Must have the ability to report on bank master L Yes
data (House Banks). Refer to Section
2.6.3
6 Must have the ability to import/retrieve and H Yes
process Bank Statement data for each predefined Refer to Section
bank account automatically and provide a manual 2.3.1
input process as a back up.
7 Must be able to ensure that Bank statements are H Yes
processed once. i.e. Control over duplicate bank Refer to Section
statement processing. 2.3.1
8 Must be able to hold all the data required to H Yes
account for bank transactions and the Refer to Section
reconciliation of those bank accounts 2.3.1
9 Must be able to allocate payments received in the M Yes Subject to RICEF
bank to the customer accounts where data is approval and further
given to support this. (E.g Merchant / Customer analysis of Bank
number) statement data.
10 Must have the ability to report on open bank H Yes
items. (Reconciliation Items) Refer to Section
2.4.1
11 Must be able to produce a Direct Debit file for H Yes RICEF Required
Amex credit card payments from customers. Refer to Section
(Specification to be provided) 2.5.1
12 Must be able to produce a Direct Debit file for H Yes RICEF Required
ASPIRE payments from customers. Refer to Section
(Specification to be provided) 2.5.1
13 Must be able to produce Direct Debit File for H Yes RICEF Required
customer direct payments Refer to Section
(Specification to be provided) 2.5.1
14 Must be able to product EFT file for payments to H Yes RICEF Required
vendors (NAB Specification) Refer to Section
2.5.1
15 Must be able to print cheques in API formats as H Yes RICEF Required
specified. (Currently two) Refer to Section
2.5.1
16 Must be able to re-print the cheque if required H Yes
and have cheque register functionality that allows Refer to Section
for a new cheque number being used, where a 2.5.1
cheque has been destroyed and provide voided
cheque lists.
17 Must be able to provide reconciliation process for H Yes
ASPIRE securitization payments from WBC to Refer to Section
NAB. This process will reconcile that all 2.5.1
payments made by Westpac are received by
NAB.
18 Must be able to calculate Merchant fee (Amex & H No Subject to RICEF
Diners)and GST based on predefined rules and approval
percentage, and post to GL
19 Must be able to process retail (corporate stores) H Yes - Refer to AR
bank transactions and provide a reconciliation BBD
mechanism for retail sales to be reconciled to
bank receipts.
20 Must be able to retrieve the bank statement file H No Not a functional
from the bank as required. team requirement.
Criticality
ID Description Met by Design Reason not met
[H/M/L]
To be transferred to
the Tech team.
21 Must be able to continue process bank H No Subject to RICEF
reconciliation when new transaction codes are approval
used by API. Undefined transcode must be posted
to a Global Clearing account for manual
processing.
Note: all bank interface file formats and sample files, included AMX, EFT, Direct Debit, ASPIRE, are upload in
Confluence.
[Link]
2 SOLUTION DESIGN
2.1 OVERVIEW
Id Description
1 SAP Standard House Bank creation process to be used.
2 SAP Standard Bank account number and Bank number length functionality to be used.
3 SAP Standard Electronic Bank Statement upload process to be used.
4 SAP Standard Bank Reconciliation functionality to be used.
5 SAP Standard Bank Reports to be used.
Id Description
1 This design incorporates SAP ‘Best Practice’ functionality.
2 Both Westpac and NAB Bank Statements will be received in a SAP standard format.
3 Only Westpac and NAB Bank accounts will be used.
4 Direct debit output files can be created using SAP standard DME engine configuration.
2.2.1 DESCRIPTION
House Banks are created at company code level. Each house bank of a company code is represented by a bank ID in the
SAP system. Every account at a house bank is represented by an account ID. In the SAP system, the bank ID and the
account ID is used to specify bank details. An authorisation process also overlays the creation / modification procedure
to ensure that all changes are appropriate from a Group or Company perspective and duly authorised.
At the time of House Bank creation system will validate the length of bank ID and account ID.
(Required length of bank ID and account ID needs to be confirm)
2.2.4 LOCATION
This function will be performed at Corporate Office
2.2.5 FREQUENCY
This function will performed only on request and infrequently.
2.2.6 DURATION
This function will take approximately between, a day to a week depending upon the approval process.
SAP uses an automated process of uploading the bank statements. API banks will provide the bank statement (in
specified format) file in a secure SAP area, using an automatic process to move the required files. Any errors with the
bank statement file (e.g. statement missing for day, statement date not correct, etc.) during the upload into SAP will be
communicated to the bank by the Bank Reconciliation Officer.
A standard control will be in place to ensure that duplicate files are not processed. This control requires the bank
statements to be loaded in numerical sequence. i.e. Bank statement 1 to be loaded before the system will allow bank
statement 2 to be loaded.
Bank Statements cannot be uploaded if an unknown “new” external transaction code exists in the file, a transaction code
that is not yet configured in the system or if the statement is not placed by the bank in the secure area at the time of
batch job schedule. Where this occurs, the Bank Reconciliation Officer will communicate with the SAP Administrator
in order to update the new external transcode in SAP, prior to rerunning the bank statement upload process,
alternatively, this can be left for the next scheduled run.
The Bank statement transactions will be processed and posted in the general ledger and where required to the sub ledger
accounts based on the transaction codes and data specified in the bank statement information. Each bank “trans code” is
assigned to a particular posting rule within SAP, which directs the postings to a nominated GL bank clearing and in
certain cases, to sub-ledger accounts.
Set out below are the posting rules for different types of bank transactions for API.
Outgoing Payments: For AP EFT payments a posting rule will be defined as follows:
Posting Entry 1 will post credit entry to Main bank account and debit entry will be posted to relevant bank clearing
account
In the case of an outgoing payment reversal, the reversal entry will be generated by the bank statement upload
process. IE Reversals will be driven by the bank entry and are equal and opposite to normal entries.
Bank Charges & Merchandise Charges: For bank charges a posting rule will be defined as follows:
Posting Area 1: SAP will post a credit entry to the Main bank account and a Debit Entry to the relevant bank charges
account. No level 2 transaction is required.
Incoming Electronic Payments, e.g. EFT, Credit Card etc.: Two posting rules will be defined as follows:
Sample Accounting Document for incoming electronic payments (without clearing customer invoices)
Posting Entry 1:
Doc DR/CR Sample Account Group Description Management Accounting Amount
Type Account
SR DR Bank - SAP Main Corporate Profit Centre 100.00
Posting Entry 1:
Doc DR/CR Sample Account Group Description Management Accounting Amount
Type Account
SR DR Bank - SAP Main Corporate Profit Centre 100.00
SR CR Bank – AR Cheque Clearing Corporate Profit Centre 100.00
A/c
In case of a dishonoured cheque, a reverse entry will be generated by the bank statement upload process based on
the Tran code for reversal.
Where a transaction is recognised (i.e. transaction type and document / customer reference and value) it is automatically
posted to the GL Bank, designated bank GL Clearing Accounts and subsequently to sub-ledger account.
For every House bank (Main Bank), API will have following Bank Clearing Accounts:
GL Account Description
Main Bank
AP Direct Debit Clearing
AP Cheque Clearing
AP EFT Clearing
AP Miscellaneous Credit Clearing
AR Cheque Clearing
AR EFT Clearing
AR EFTPOS Clearing
AR Direct Debit Clearing
AR Miscellaneous Credit Clearing
AR Branch Cash Clearing
AR Merchant Credit Card Clearing
Sweeping Clearing
Treasury Clearing
Payroll Clearing
Examples of sample accounting documents and bank clearing accounts needs to be updated after finalising the posting
rule details
Visio Hyperlink
Document
Name
Electronic [Link]
Bank Electronic+Bank+Statement+[Link]
Statemen
t upload
process
2.3.4 LOCATION
This function will be performed at Corporate Office
2.3.5 FREQUENCY
This function will be performed daily.
2.3.6 DURATION
This function will take approximately between 15 to 30 minutes if there are no processing errors but could take days if
the bank needs to make changes, or if trans codes need to be updated.
2.4.1 DESCRIPTION
The purpose of the bank reconciliation process is to review postings generated by the electronic bank statement and
attend to unreconciled items that have arisen. All bank postings are posted to the Bank GL and one of the many bank
GL Clearing accounts. Unreconciled items will be those uncleared items in the bank GL clearing accounts. These
transactions will result bank postings where the source transaction has not yet been associated with the bank entry, or
when the originating item has yet to be processed through the bank. The clearing processes should be run on a daily
basis to ensure clearing of open items are completed regularly so that only legitimate unprocessed items remain.
Bank reconciliation officers should check that the balance on the physical bank statement agrees with the GL Bank
account on a daily basis. The Bank GL account must always reflect the transaction that occur on the bank statement and
therefore will always equal the balance per the bank statement.
Apart from the day-to-day allocation of unreconciled items, the monthly bank reconciliation process will be performed
by the appropriate departments (AR, AP, Treasury, etc.), which includes the following steps:
Analysis and posting of proposed sub ledger postings that have not yet been posted. (AR payments received not
posted to customers)
2.4.4 LOCATION
This function will be performed at Corporate Office
2.4.5 FREQUENCY
This function will be performed daily. Additional checks will be conducted at month end.
2.4.6 DURATION
The amount of time taken for this process will depend on the quantity of data needing to be processed, the staff doing
the processing and the accuracy of bank data.
2.5 PROCESS DESIGN – BANK FILES FOR CUSTOMER AND VENDOR PAYMENTS
2.5.1 DESCRIPTION
The following DME Bank files are required for customer’s payments.
For the process details of the above mentioned files please refer to Accounts Payable BBD for Vendor payments and
Accounts Receivable BBD for Customer payments.
2.5.4 LOCATION
This function will be performed at Corporate Office
2.5.5 FREQUENCY
This function will performed on a daily basis
2.5.6 DURATION
The files will be created immediately on request.
The following table lists the document types defined for XXXX Bank processing.
Document Description / Purpose Reversal Description
Type Document
Type
SR Bank Reconciliation SB G/L Account Posting
SB G/L Account Posting AB Accounting Document
Posting Rules
Posting Rule Text
ID Name Description Audience Key Criteria Fields Key Output Fields Frequency Type
[Daily, Weekly, Monthly, Yearly, [SAP Standard / BI / Custom]
Adhoc]
1 S_P99_41000166 Bank Master Data Report SAP Standard
ID Name Description Data Data Volume Cleansing Extraction Transform Load Details
Source Owner Details Details Details
ID Name Description Audience Trigger Output Types Volume / Key Output Fields
Frequency
[Daily, Weekly,
Monthly, Yearly,
Adhoc]
Cheque Form As per file specifications from
NAB
2.6.8 AUTHORISATIONS
<Vendor: Specify authorisation requirements, such as segregation of duties, for any of the roles in the business process.
Note: only valid roles from the Business Process Master List may be used>