Payment accounts and treasury

Payment accounts and treasury, in brief

Payment Accounts in Skyline Nexus ERP are the cash boxes, bank accounts and card-clearing accounts a business actually holds money in day to day; Treasury is the wider set of screens built on top of them, covering receipts, payment vouchers, cheques, transfers, petty cash, cash advances and bank reconciliation. It matters because every sale, purchase or expense a business records has to be paid into or out of one of these accounts, and which account is used is what a payment method's default routes to at each branch.

This guide covers Payment Accounts themselves, how a branch's payment methods route to a default account, and moving money between accounts with Fund Transfer and Deposit. It does not repeat bank reconciliation in Skyline Nexus ERP, which already covers matching a bank statement to the books in detail.

Two related but different things: Payment Accounts and the ledger

Payment Accounts, reached from the Payment Accounts menu, are a simple register: List Accounts, Balance Sheet, Trial Balance, Cash Flow and Payment Account Report. They are useful for a quick read of cash and bank positions, but they are not the double-entry general ledger, and a Payment Account is not itself a chart-of-accounts entry: creating one does not create a Fiscal Authority GL account, and the two are not linked by any field on the account record.

What decides which GL account actually absorbs cash and bank activity is Fiscal Authority, Settings, the Default Cash Account and Default Bank Account mapping. For financial statements, always work from Fiscal Authority's own reports; treat Payment Accounts as the operational cash and bank register that feeds the branches' day-to-day payment screens. The two are meant to tell a consistent story even though they are separate records: if the Payment Account Report and the Fiscal Authority cash and bank balances start drifting apart, that is a sign a document has posted on one side without a matching movement on the other, and it is worth chasing down while the gap is still small.

Before you start

A small amount of account structure up front avoids a business discovering, months in, that every branch's till and every bank account have been sharing one generic Payment Account, at which point separating the history back out branch by branch is far harder than setting it up correctly would have been.

• Decide the Account Types needed (for example Cash and Bank as parents, with specific tills or accounts as sub-types)
• Create one Payment Account per real cash box or bank account, not one shared account for everything
• Know each account's real opening balance before entering it, since it is set once at creation
• Confirm the Default Cash Account and Default Bank Account are set correctly in Fiscal Authority Settings
• Assign the right Default Account to each payment method on every business location

Setting up Payment Accounts and account types

Go to Payment Accounts, List Accounts, Add Account. Fields are Name, Account Number, an Account Type (built from the types created under Add Account Type, with sub-types grouped under a parent), an Opening Balance, and an Account Details table of up to six free-form label and value rows for anything else worth recording against the account, such as an IBAN or a branch sort code.

Account Types themselves are simple: a Name and an optional Parent Account Type, which is what lets several tills be grouped under a Cash parent, and several bank accounts grouped under a Bank parent, so reports can be read at either level. Naming accounts by what they physically are, such as Till 1 Riyadh or Main Account ING, rather than a generic Cash or Bank, is what makes the Payment Account Report and Cash Flow screens useful once there is more than one of each.

The Account Details table is easy to skip past but worth using: recording a bank account's IBAN, sort code or the branch it belongs to directly on the account means that information is sitting where a payment is actually being recorded from, rather than in a separate spreadsheet someone has to go and check. For a cash till, the same table can hold who is responsible for counting it, which matters when several people share a shift.

Linking payment methods to a default account

A business location's payment methods, set on Settings, Business Locations, each carry a Default Account column, and this is the field that decides which Payment Account a location's cash sales, card settlements or bank transfers land in. A location with one till and one bank account can point every method at the same two accounts; a location with several tills or a separate card-settlement account should point each method at the specific account it actually settles to.

Getting this mapping right at each branch is what makes the Payment Account Report trustworthy branch by branch: a card payment method still pointed at the generic Cash account, for instance, will make the till look busier than it is and the real bank-settlement account look emptier than it is, purely because of where the default was left pointing.

Moving money: Fund Transfer and Deposit

Two actions move money between Payment Accounts directly. Fund Transfer asks for Transfer from, Transfer To, an Amount, a date and a Note, plus an optional Attach Document, for moving money between two of the business's own accounts, such as banking part of the week's takings. Deposit asks for Deposit to (the receiving account), an Amount, an optional Deposit From describing the source, a date and a Note, for money coming into an account from outside the two-account transfer pattern.

Neither action is documented as posting a Fiscal Authority journal on its own: they move balances within the Payment Accounts register itself, which is exactly what the Cash Flow and Payment Account Report screens then read from. A business that also wants a specific transfer reflected in the general ledger trial balance records it separately with a manual journal entry between the ledger's own cash and bank accounts, dated the same day, so the two records agree.

Both screens also take a Note, and Fund Transfer takes an Attach Document, which is worth using for anything larger than routine till banking: a bank transfer confirmation or a deposit slip attached at the time is far easier to find later than trying to match a bank statement line back to a transfer six months afterwards from memory alone.

Worked example: banking the week's cash in euros

A Dutch bakery's till, Payment Account Till 1, holds EUR 3,000 at the end of the week. The owner keeps EUR 500 as a float and banks the rest through Payment Accounts, Fund Transfer: Transfer from Till 1, Transfer To Main Account ING, Amount 2,500, dated the same day, noted as the weekly cash deposit. Till 1's balance in the Payment Account Report drops to 500 and Main Account ING's rises by 2,500, immediately and without touching a single sale or expense already recorded.

Because Fund Transfer is a Payment Accounts movement rather than a Fiscal Authority posting, the bakery's bookkeeper also records the same movement as a manual journal in Fiscal Authority, dated the same day, so the GL trial balance matches the till and bank positions the Payment Account Report shows.

• Payment Accounts: Till 1 falls by 2,500.00, Main Account ING rises by 2,500.00
• Matching Fiscal Authority journal: Dr Bank 2,500.00
• Matching Fiscal Authority journal: Cr Cash 2,500.00

Treasury: the wider cash and bank workstation

Treasury, under the divider Treasury Governance and Control Centre, is the fuller set of cash and bank screens: Receipts, Payment Vouchers, Salary Vouchers, Credit Notes, Cheques (Received Cheques, Issued Cheques, PDC Management, Cheque Books), Transfers, Petty Cash, Cash Advances, Expense Claims, Bank Accounts, Bank Reconciliation, Smart Import, Payment Processing and Approvals. Treasury's own Bank Accounts are synced into the chart of accounts through Fiscal Authority, Settings, Bank Account Sync, and the trial balance warns when a Treasury bank account has not been synced. Treasury also has its own Transfers screen, distinct from Payment Accounts' Fund Transfer, used specifically for moving money between two of a business's own bank accounts in a way that bank reconciliation can match cleanly on both statements.

Petty Cash and Cash Advances in Treasury are what the Payment Source and Select Cash Advance fields on Add Expense and Add Purchase actually draw from, so an employee's float can be topped up, spent against, and reconciled without every small purchase needing its own bank payment. Cheques, similarly, run through their own registers rather than through Payment Accounts directly, with PDC Management specifically for post-dated cheques that should not be counted as cash until the date they actually clear.

Common mistakes and how to fix them

Most Payment Accounts problems come from treating the register as an afterthought rather than a structure worth setting up deliberately, and every one of them is cheaper to fix in the first week than after months of transactions have piled up against the wrong account.

• One shared Payment Account standing in for every till and bank account, making the Payment Account Report meaningless per location
• A payment method's Default Account left pointing at the wrong account after a new till or bank account is added
• Assuming a Fund Transfer or Deposit has updated the Fiscal Authority trial balance, when it only moved the Payment Accounts balance
• Treasury Bank Accounts left unsynced, so the trial balance's warning is ignored instead of acted on
• An opening balance entered on the wrong account, which then has to be corrected with an offsetting transfer instead of being right from day one

Related reports

Payment Accounts and Treasury feed several reports that read the same underlying money movements from different angles.

• Payment Accounts, Cash Flow and Payment Account Report, for the operational cash and bank position by account and by branch
• Treasury, Reports, Daily Cash Position and Bank Balance Summary
• Fiscal Authority, Reports, Cash Flow and Trial Balance, for the general ledger's own cash and bank position
• Fiscal Authority, Reports, Data Verification, to compare Payment Accounts, Treasury and the general ledger side by side
• Treasury, Bank Reconciliation, for matching a bank statement against Treasury's own bank accounts