SAP Bank accounting

It manages how money physically moves: defining bank accounts (house banks), processing incoming/outgoing payments, importing and reconciling electronic bank statements, and clearing the bank accounts in the G/L against actual bank activity. It is where the ledgers meet the bank.

• House banks & bank accounts: the organisation’s banks.
• Payment program (F110): outgoing payments to vendors.
• Electronic Bank Statement (EBS): importing and auto-reconciling statements.
• Bank reconciliation & clearing.

The design that confuses people first is that a payment does not post directly to the bank account. It posts to a clearing account, and the bank account is only touched when the statement confirms the money moved.

So a payment run credits a bank outgoing clearing account and debits the vendor. Later, the bank statement shows the payment leaving, and that entry debits the clearing account and credits the actual bank general ledger account.

The reason is timing and truth. The moment you instruct a payment is not the moment the money moves, and the general ledger's bank account should reflect what the bank says rather than what you intended. A balance on the clearing account is therefore meaningful: it is payments issued and not yet seen on a statement, which is exactly the reconciling item an accountant expects.

Several clearing accounts usually exist, one per payment method, because a cheque outstanding for three weeks and a transfer clearing same day behave differently and mixing them makes the balance unreadable.

The same pattern applies incoming: a customer payment posts to an incoming clearing account and is cleared when the statement confirms receipt.

Most of the effort in bank accounting is processing statements automatically, and the mechanism is worth understanding because it is where the reconciliation percentage comes from.

The bank sends a file in a standard format. The system reads each line and uses interpretation rules and posting rules to decide what it means: is this a customer payment, a vendor payment clearing, a bank charge, an interest posting.

The valuable part is automatic clearing. A customer payment line carrying a reference that matches an open invoice clears it without anybody touching it. One with no usable reference posts to a suspense account for somebody to allocate manually.

That is why the automation rate depends as much on customers quoting references as on configuration. The practical lever is often on the invoice rather than in the system: making the reference prominent and machine readable moves the match rate more than any rule.

Lines that cannot be interpreted at all go to a post-processing worklist, and the size of that worklist each morning is the honest measure of whether the setup is working.

Half an hour, and it makes the two-step design obvious.

1. Post a vendor invoice, then pay it with F110.
2. Open the payment document. The vendor is cleared and the credit went to a bank clearing account, not to the bank account.
3. Check the bank clearing account balance. It now holds your payment.
4. Import or enter a bank statement containing that payment.
5. Read the resulting postings: the clearing account is debited and the bank general ledger account is credited. The clearing account is back to zero for that item.
6. Now look at what did not clear automatically, and post-process one line manually.

Step three is the state that exists between instruction and confirmation, and understanding it is what makes bank reconciliation make sense.

Bank accounting connects to AP (vendor payments), AR (customer receipts), and the G/L (bank and clearing accounts). Automated EBS processing reconciles bank statements to open items, a major efficiency and control point. In S/4HANA, Bank Account Management centralises bank master data.

Cash management sits above all of this, using the same data to forecast liquidity: what is expected in from receivables, out to payables, and what the balances are today. That forecast is only as good as the payment terms and the open item accuracy underneath it, which is why bank accounting, receivables and payables are usually one team's problem. See FI closing for where reconciliation lands in the period end.

• How many house banks and accounts. Enough to reflect the real banking arrangements, and each one carries configuration and a reconciliation.
• One clearing account per payment method or fewer. More makes each balance readable; fewer is less configuration and a harder reconciliation.
• Statement format and frequency. Daily import is what makes automatic clearing useful; weekly means the receivables ledger is always days out of date.
• Tolerance for automatic clearing. Matching within a small difference and writing off the remainder is efficient, and the limit is a finance decision.

Posting a payment and sending it are separate steps, and the second is where format and compliance questions live.

The payment medium workbench generates the file the bank receives, formatted to that bank and country's requirements. Older configurations used classic payment programs, and new implementations use the workbench.

Formats are country and bank specific. ISO 20022 is the widely adopted standard in many regions, and plenty of banks still want their own variant, which is why format configuration is per house bank rather than global.

The file has to reach the bank, and how is a real design decision: a portal upload, a managed file transfer, or a direct host-to-host connection with certificates and a key exchange. That last one is more secure and involves the bank's technical team.

Positive pay and similar controls send the bank a list of expected payments so they can refuse anything else, which is a fraud control worth knowing exists.

The check that catches most problems: a payment run that posted successfully has not necessarily produced or sent a file, and reconciling what was posted against what the bank confirms is the only way to know.

Bank accounting records what happened. Cash management uses the same data to answer what is going to happen, which is what a treasurer actually needs.

The cash position is short term and near certain: today's bank balances plus known movements over the next few days, built from bank statements and payment runs.

The liquidity forecast is longer and less certain: expected receipts from open receivables at their due dates, expected payments from open payables, plus planned items that have no document yet.

The forecast is only as good as its inputs, and the two that matter most are payment terms, which decide the expected date, and the honesty of open item management. A receivables ledger full of items nobody expects to be paid on time produces a forecast that is precise and wrong.

Bank account management maintains the accounts themselves as master data: which banks, which accounts, who is authorised to sign, and the approval workflow when one is opened or closed.

The practical consequence is that improving the forecast is usually a receivables exercise rather than a treasury one, which is not where the request tends to come from.

• Manual reconciliation instead of automated EBS.
• Unreconciled clearing accounts accumulating.
• Wrong house-bank configuration breaking payments.

• An ageing bank clearing balance. It means payments issued that the bank never showed, or statement lines that never cleared, and both need investigating rather than carrying.
• Posting directly to the bank general ledger account. It breaks the reconciliation the clearing pattern exists to provide.
• A post-processing worklist that grows. See taxes, asset accounting and FI troubleshooting for the neighbouring areas.

Importing a statement is straightforward, and configuring the posting rules so most lines clear themselves is the part you do in the course.