Enter opening balances

When you switch to TALISK_HQ mid-stream, enter the balances your books started with:

1. Go to Ledger › Accounting › Opening Balances.
2. Set Balances as of: the last day your old books cover. Your TALISK_HQ books begin the next day, and that next day is your conversion date.
3. Fill each account's balance under Assets, Liabilities, Equity, and (mid-year) Revenue and Expenses. The footer shows Debits, Credits, and the Difference.
4. Click Save opening balances.

TALISK_HQ posts one balanced journal entry on the as-of date. If your entries don't fully balance, the remainder is booked to an equity account: at a year-end date that's retained earnings; mid-year it flags a likely typo.

Money that moved before your conversion date is already inside these balances. That is why TALISK_HQ refuses to record a GST/HST or QST payment or refund dated before it, from the GST/HST tab or from a bank line: the refusal names the date and sends you here, because a wrong figure is fixed in the opening balances, not by recording the money a second time.

A receipt counts by the day it was paid, because that is the day its expense is recorded. A receipt dated before your conversion date but paid after it stays in your books, and so does any card charge entered on it; one paid before the conversion date is inside the opening balances, whatever date it carries.

TALISK_HQ also refuses an as-of date that would split a store payout from its sales-tax correction. If a payout falls inside the opening balances but its correction is dated after the as-of date, the correction would stay in the books and count that payout's sales and tax a second time. The refusal names the payout and the correction's date: use balances as of that date or later, and ask your accountant for a trial balance as of that date if you need one.

Re-saving replaces your existing opening entry, not adds to it. If the as-of date is inside a locked period, remove the lock first.

Moving the as-of date earlier than your existing entry does more than replace it. Bills, bank lines and payouts dated between the two dates (and receipts paid between them) were inside your old opening balances; after the move they are after it, so TALISK_HQ brings them back into your books. A store payout paid out after your old date can hold back sales made before it; the sales made after the new date come back too, and TALISK_HQ re-works that payout at the new date. Before anything is saved, the screen tells you how many records that is, and Move and save confirms it. Your balances as of the earlier date should leave those records out. Some records cannot be brought back automatically: a payment or settlement recorded in that period, a bank line recorded as a refund, a credit, a transfer or a remittance, a cancelled bill, a third-party payroll payment, a customer deposit, a proposed refund on a direct sale, a receipt match that booked a difference between the receipt and its bank line, a posted stock count, a store payout holding back sales that cannot be re-worked (it carries a sales-tax correction, an earlier conversion split it, its cost of goods is posted, it is in a foreign currency, or the order details are not in TALISK_HQ), a store payout that may have been in your books before but cannot be posted again (its payment provider does not show it as paid out, posting from that provider is paused, its payout record is gone, or an account it posts to is missing from your chart), or an entry dated in that period that belongs to a bill with no date or to an earlier bill (such as a card charge adjustment posted after a period lock). When the period holds one, the screen says what it found, and the opening date stays where it is. Some of these come back after all, because nothing they posted can be lost: a cancelled receipt with no card charge adjustment comes back with its expense and its cancellation (unless the cancellation was dated on a different day from the expense), anything you discarded comes back as it was, a stock count you never posted comes back with no entry, and a receipt matched to a bank line comes back with its receipt when the match booked no difference (the amounts agreed, or the receipt was attached to a line that was already booked). Clearing your opening balances first does not get around this: the next earlier date is checked the same way.

A store payout paid out after your old as-of date can carry sales from on or before it. Setting that date divided the payout: its earlier months went into your opening balances and the rest stayed in your books. Moving the date earlier puts that payout back together, then divides it again at the new date if it still carries sales from on or before it. That works at a month end, and it works too when a later date has since moved the whole payout into your opening balances.

A store payout coming back this way is refused, and the opening date stays where it is, when TALISK_HQ cannot rebuild it, cannot post it again, or cannot divide it at the new date:

• It can't be rebuilt. TALISK_HQ has no record of how it stood before it was divided, or only a record made after an earlier division; it was corrected for sales tax since; or some of its sales were held out of it when it arrived, as being before the conversion date of that time, and the new date would bring them back (or TALISK_HQ has no record of that date).
• It can't be posted again. It predates the rules that check a payout's sales tax before posting it, an account it posts to can't be found, nothing records which of its sales belong to which month, or what it moved out doesn't line up with the months it covers.
• It can't be divided at the new date. The new date falls in the middle of a month its sales run across (a payout's sales are recorded by month), a locked period would push one of its months to a later date, or a month that stays carries refunds whose tax was spread across several taxes, or whose tax as posted doesn't match the refunds.

The screen names each of these payouts before anything is saved. In rare cases a payout would post its months differently from how they were first posted (for example, its cost of goods has changed since); that is found only when you save, and the save is then refused with nothing changed.

To pull your opening balances from your old software's trial balance, use Import from accountant documents: it accepts a PDF, Excel (.xlsx), or CSV file, and a spreadsheet export is read directly. Note that QuickBooks Online exports a trial balance to Excel only, so the .xlsx file is the QuickBooks route; Xero exports both.

If your export doesn't say which accounts are assets, liabilities, equity, income, or expenses, which a QuickBooks Online trial balance doesn't, the review screen asks you to choose a type for each one before you can apply the chart. TALISK_HQ never guesses: the wrong type would put a balance on the wrong statement. To skip that step, export with the types included (in Xero, tick Group by Account Type) or upload the PDF instead. When a spreadsheet is read, the review screen also states which Debit/Credit columns it used, the totals it read, and whether your amounts were read with comma decimals (1 234,56, the format Excel writes on a French-language machine), so you can check that's the right set of figures before anything is applied.

When you import a trial balance, a short bank accounts step appears between the chart review and this screen: rows that look like bank or card accounts are offered to become accounts in Banking, each showing the balance your trial balance carries so you can verify it. The step is optional and every row can be skipped. Nothing is booked there: each account's starting balance reaches Banking when you post your opening balances here.

Moving over from another package? Switch from another accounting system walks the whole path end to end.