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 new Fiscal Authority GL account. Some Payment Accounts do carry a link to an existing GL account behind the scenes, though: the Cash and Bank accounts Skyline Nexus ERP sets up at sign-up are linked to GL 1101 Cash on Hand and 1110 Bank respectively, which is what lets a Fund Transfer or a Deposit involving them post to Fiscal Authority automatically, covered further down.

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.

Both actions now post a Fiscal Authority journal automatically, provided the Payment Accounts on both sides of the movement are linked to a GL account, which the Cash and Bank accounts created at sign-up are by default. Fund Transfer debits the receiving account's GL account and credits the sending account's; Deposit debits the receiving account's GL account and credits the source account's GL account where a Deposit From account is chosen, or Share Capital where it is not, for example an owner putting personal money into the business. Editing a movement reverses the old journal and posts a new one, and deleting it reverses the journal too, so the Payment Accounts register and the Fiscal Authority ledger move together rather than needing to be kept in step by hand. A side of the movement that is not linked to a GL account is simply skipped rather than guessed at, which an administrator can turn off business-wide under accounting_settings.auto_post_fund_transfers if it is not wanted, though it is on by default.

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.

Till 1 is linked to GL 1101 Cash on Hand and Main Account ING is linked to GL 1110 Bank, so the same Fund Transfer also posts a Fiscal Authority journal the moment it is saved, with no separate manual entry needed: it debits the receiving account's GL account and credits the sending account's, and the two sides balance exactly, so the bakery's trial balance moves in step with the Payment Account Report automatically.

• Payment Accounts: Till 1 falls by 2,500.00, Main Account ING rises by 2,500.00
• Automatic Fiscal Authority journal: Dr Bank 2,500.00 / Cr Cash 2,500.00
• Check: 2,500.00 debits = 2,500.00 credits

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 always reaches the Fiscal Authority trial balance: it only posts automatically when both Payment Accounts involved are linked to a GL account, so a side with no link is skipped rather than guessed at, and is worth checking on the Data Verification report
• 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