Setting Up a Bank Account for Scheduled Tax E-Payments

When you schedule tax payments electronically, the software asks you to pick a bank account from your chart of accounts before it will let you finish. That request confuses a lot of bookkeepers, because the money never sits anywhere new. Here is what is actually going on, and how to keep the ledger tidy around it.

Why the setup insists on a bank account

An e-payment is not a transfer of funds through the software vendor. The vendor acts only as a transmitter: it passes payment instructions and your bank details to the tax agency, and the agency debits your real bank account directly. Nothing is held in between.

Because the debit lands in your operating bank account, the payment has to be recorded against that same account in the ledger. The setup screen is simply forcing you to name the account the agency will pull from, so the generated payment transactions post to the right place. Without it, the software has nowhere to book the cheques and the liability settlement.

What this means for your chart of accounts

You need a bank-type account in the chart of accounts representing the account the agency will debit. Usually that is your existing operating account. You do not need a separate account just for e-payments unless your client deliberately wants tax payments segregated, which is a policy choice, not a requirement.

If payroll setup stops you with a message that no bank account exists, you can pause the setup. Entries already made are saved, and you can return after adding the account. Add the bank account, then resume and select it.

How the payments should hit the ledger

Each e-payment should clear the payroll liability it settles, not post as a bare expense. The expected pattern is a debit to the tax payable liability account and a credit to the bank account. That keeps the liability sub-ledger, per agency and per tax type, walking down to zero as payments land.

Watch the timing. The agency debits the bank on or just after the payment date, but the bank feed item may arrive a day or two later. Match the feed item to the generated payment rather than adding it, or you will double-post and break the reconciliation.

Where this fits in the close

At month-end, confirm three things: the liability balances agree to the agency notices, the e-payments generated in the period appear as cleared or outstanding items on the bank reconciliation, and any payment dated near the cut-off debited the bank in the period you recorded it. A payment recorded in one month that leaves the bank in the next is a reconciling item, not an error, but it needs to be listed.

If payments post to the wrong account, or the liability refuses to clear after an e-payment, that is usually a setup or mapping question you can fix in the ledger. If instead the file shows damage, duplicated payment records, or a reconciliation that will not hold after correction, that moves beyond bookkeeping. In that case, preserve a backup and a copy of the reconciliation reports before anything is touched, and hand it to a data repair specialist.