Making payments in NAB Connect, without the guesswork

Four kinds of payment, four different journeys

New users often treat "make a payment" as one action. In a business platform it is at least four, and picking the right one matters because each travels differently, costs differently and can be undone — or not — differently. Pay Anyone is the direct transfer to an Australian bank account using a BSB and account number: supplier invoices, refunds, one-off reimbursements. BPAY pays bills using the biller code and reference printed on the bill — utilities, council rates, tax-office style payments where the biller gives you those details. Batch payments move many payments in one file or one session — the payroll run, the weekly supplier round — created together and authorised together. International payments send money overseas in Australian or foreign currency; they are enough of a world of their own that they have their own guide on this site, international payments in NAB Connect.

Whichever kind you choose, the journey has the same shape: a payment is created with its details, checked (by a second person, in any well-run setup), authorised with a token confirmation, then processed by the bank and received at the other end. When someone says "the payment has not gone through", the useful question is always: which stage is it sitting at? A payment awaiting authorisation, a payment authorised after a cut-off, and a payment that left on time but is clearing slowly are three different situations with three different fixes — and only one of them involves anything being wrong.

Paying a person or business: details, descriptions and the name problem

A Pay Anyone payment needs three things: the recipient's BSB, their account number, and an amount — plus, if they are new, a place in your beneficiary list. Two habits separate smooth payers from sorry ones. The first is verification of new details. The first time you pay a supplier, the account details should be confirmed through a channel independent of the invoice that carried them: ring the supplier on a number you already trust and read the BSB and account number back to them. Invoice fraud in Australia overwhelmingly works by sending a genuine-looking invoice with quietly altered bank details; the thirty-second confirmation call is the cheapest insurance in business. The second habit is meaningful descriptions. The reference you type is what the recipient sees on their statement and what your future self searches for at reconciliation time. "INV 2041 March" ages well; "payment" does not. Where the recipient uses payment references to match incoming money — real estate agents, wholesalers, anyone with a reference field on their invoice — copy their reference exactly, character for character.

Now the name problem, because it startles everyone once: for standard Australian transfers, the account name is generally not checked against the account number during processing. Money follows the BSB and account number. Type a digit wrong and the payment can land in a stranger's account attached to a completely different name, and retrieving it is a process, not a button. (Newer confirmation-of-payee style checks are rolling out across Australian banking and may warn you when a name does not match — treat any such warning as a full stop, never as a formality to click through.) This is why careful businesses read the digits back off the invoice at authorisation, and why the checking stage in the workflow exists at all. If you do send money to a wrong account, speed matters: contact the bank as soon as you realise, because mistaken payments are far easier to recover before the recipient spends or moves the funds. Our security guide covers the fraud side of beneficiary changes in more depth.

BPAY: the quiet workhorse for bills

BPAY payments run on two numbers printed on the bill: the biller code, which identifies who you are paying, and the customer reference number, which identifies which bill — and often which customer account — the money belongs to. Get the biller code right and the reference wrong and your money reaches the right company attached to the wrong account, which is its own special flavour of mess. Transcribe both numbers carefully, and use the reference from the specific bill in front of you: many billers issue a fresh reference per bill, so last quarter's payment copied forward can misfire even though the biller is unchanged.

Timing deserves respect with BPAY. A BPAY payment made on a business day before the bank's cut-off is generally treated as received by the biller that day; one made after the cut-off, or on a weekend or public holiday, is generally treated as received on the next business day, even though the money leaves your account when you authorise it. Interest, late fees and disconnection notices are calculated on the biller's received date, not your sent date. For bills with hard deadlines — tax obligations, insurance renewals, anything with a "pay by" date that has teeth — pay at least one business day early and keep the receipt details. Saving your regular billers in the platform, with their exact references for recurring arrangements, removes the transcription risk for the bills you pay every month; just re-check the reference whenever a biller tells you it has changed.

Batch payments and the two-person workflow: where control lives

A batch collects many payments — twenty wages, forty supplier invoices — into a single unit that is created once and authorised once. Businesses build batches two ways: by keying payments into a batch inside the platform, or by uploading a file produced by their accounting or payroll software. The file route is where errors scale, so it deserves a routine: check the file's total and count against your payroll or payables report before authorisation, every time. A batch whose total matches the source report to the cent is almost certainly the batch you meant to send; a batch that differs by one payment's worth tells you exactly where to dig. Authorisers should treat the total-and-count check as the job, not a courtesy glance — most batch disasters (a duplicated file, last week's file re-uploaded, a terminated employee still on the list) are visible in those two numbers.

The two-person pattern only works if the second person genuinely checks. An authoriser who approves whatever appears, on the logic that the creator is careful, has quietly converted your two-person control into a one-person control with extra clicks — and auditors and insurers assess it exactly that way. Practical authorisation checks that take under a minute: the total matches the source report; any new or changed beneficiary is flagged and verified (this single check defeats most invoice fraud); the payment date is the intended date, not a defaulted wrong one; and the from-account is the right account, which matters more than anyone expects in businesses with several. If your setup lets the creator and authoriser be the same login, read our user setup guide and fix the roles — the platform's controls can only enforce the separations you have actually configured.

Cut-off times explained: the invisible deadline inside every payment

A cut-off time is the moment after which the bank treats a payment as belonging to the next business day's processing, even though you authorised it today and the money may leave your account today. Cut-offs exist because interbank settlement runs in scheduled cycles, and they differ by payment type: same-bank transfers are generally the most forgiving, payments to other Australian banks have their own daily deadlines — commonly in the late afternoon or early evening, Australian Eastern time — and BPAY and international payments run to their own clocks. The bank publishes the current times for each payment type; treat any specific hour you read anywhere (including older guides) as indicative only and check the current published time before you rely on it for a deadline that matters.

Three cut-off traps recur. The daylight-saving trap: cut-offs are set in eastern time, so if your business is in Perth or Adelaide, your local deadline moves relative to your clock when daylight saving starts and ends — a payment routine timed to the minute in winter can silently become a late payment in summer. The authorisation trap: the cut-off applies when the payment is authorised, not when it was created. A batch created at noon and authorised at the end of the day is an end-of-day payment, whatever the creator intended. The weekend trap: payments authorised on Saturday for Monday's wages are fine because they are future-dated or next-business-day by design — but a payment authorised Friday after the cut-off may not move until Monday's run, which is a nasty surprise if staff check their accounts on Saturday morning. Build your payroll routine backwards from the cut-off with a day's slack, and the traps mostly disarm themselves.

Payment limits, and tracking a payment when someone asks "where is it?"

Limits operate at several levels at once, and a payment can be blocked by any of them: your personal authorisation limit (set by your administrator — see the setup guide), any daily or per-payment limit on the account or facility, and product-level rules such as minimums or maximums for particular payment types. When a payment refuses to proceed, the limit involved is usually identifiable from where it stopped: a creator can build a payment of any size, but the release fails when it exceeds the authoriser's limit, which is the system working as designed. The fix is a higher-limit authoriser or a deliberate, recorded limit change — never splitting one payment into smaller pieces to sneak under a limit, a practice called structuring in other contexts and a red flag in all of them.

Tracking. When a recipient says a payment has not arrived, work the stages from the flow diagram at the top of this page. First, confirm inside the platform that the payment's status shows it as authorised and processed — not sitting in a pending or awaiting-authorisation list, which is the answer more often than anyone expects. Second, check the date logic: was it authorised after a cut-off, on a weekend, or future-dated by accident? A striking number of "missing" payments are simply payments whose value date is tomorrow. Third, verify the destination digits against the source document — one wrong digit in the BSB or account number means the money went somewhere real, just not to your supplier. If all three checks pass and the payment shows as processed, the recipient's bank and its own posting schedule are usually the remaining explanation; payments to other banks can take until the end of the business day, and occasionally the next one, to appear. Give the recipient the payment details from the platform record — date, amount, reference, and the receipt or transaction details the platform provides — rather than a screenshot of your account, and if a payment is genuinely lost, the bank can initiate a trace. Traces take time and may attract a fee, which is one more argument for the thirty-second verification call before the first payment to any new beneficiary.

1. Confirm the status in the platform

   Processed, pending, or awaiting authorisation? Half of all "missing payment" calls end at this step.

2. Check the value date

   Cut-off passed, weekend, public holiday, or a future date chosen during creation — any of these makes "tomorrow" the correct arrival.

3. Re-verify BSB and account number against the source

   Digit by digit, from the original invoice or document — never from the payment itself, which only proves it matches itself.

4. Arm the recipient with the record

   Date, amount, reference and platform receipt details let their bank find the money at their end.

5. Escalate to a trace if it is truly lost

   Contact the bank with the payment details. Mistaken-destination payments are time-sensitive, so do not let a trace wait a week out of politeness.

The payments routine that rarely makes the news

Businesses that never feature in payment horror stories share an unglamorous rhythm. Payments are prepared at a set time, not in fragments between other jobs. New beneficiaries are verified by phone before the first payment and their details re-confirmed whenever a "we have changed banks" email arrives — that email, specifically, is treated as guilty until proven innocent, because it is the single most common fraud approach to Australian businesses. Batches are reconciled by total and count before authorisation. Cut-offs are known, written on the wall if necessary, and payroll is scheduled a day ahead of them. Receipts and platform records are filed where the bookkeeper can find them at month end, which makes the day-to-day work described on our homepage run on rails. None of this requires new software or new staff. It requires only the decision that payments deserve a routine — because the money, once it leaves, does not care how busy the morning was.

Future-dated and recurring payments: convenience with a memory problem

Most business platforms let you date a payment for the future and set regular payments to repeat — rent, subscriptions, monthly retainers, the BAS rhythm. Used well, scheduling removes deadline stress entirely. Used carelessly, it creates payments that fire long after everyone has forgotten why they exist. The disciplines are simple. Review future-dated payments whenever the underlying facts change: a supplier whose prices rose, a lease that ended, a staff member whose salary changed — each should trigger a look at what is queued, because a scheduled payment authorises itself against yesterday's reality. Keep a register of recurring payments outside the platform as well: what, to whom, how much, how often, and the business reason. The register takes ten minutes to build and turns the annual "what is this $340 a month?" investigation into a lookup. Watch the first run of anything new. A recurring payment's first occurrence is where wrong amounts, wrong references and wrong beneficiary details announce themselves; check it landed correctly before letting the pattern repeat twelve times. Mind date collisions: a payment scheduled for the 31st meets February eventually, and a payment dated for a public holiday slides to the next business day whether or not your cash flow planned for the slide. For obligations with genuine deadlines — tax, rent, insurance — schedule a business day early and let the buffer absorb the calendar. Finally, when a staff member who created scheduled payments leaves, those schedules belong on the departure checklist in our setup guide: review each one, reassign ownership, and cancel anything whose reason left with them. A payment nobody remembers creating is a payment nobody is checking — the exact habitat of slow, quiet losses.