ERP system development
in Toronto

An ERP becomes the place where the books of a business actually live. Invoices, journal entries, payroll runs, purchase orders and the documents behind them all end up in its database. In Canada that carries a specific obligation. The Canada Revenue Agency expects a business to keep adequate books and records, generally for six years after the end of the tax year they relate to. It expects electronic records to stay in a readable electronic form. And it expects them to be available for examination from Canada when an auditor asks.

None of this is exotic. It becomes a design problem only when nobody writes it down before the build. A custom ERP decides a great deal by default: how long rows survive, whether edits overwrite, where scanned receipts are stored. Each default either supports the obligation or quietly works against it.

Start with retention. Many systems ship with purge jobs that clear old transactions to keep tables small and screens fast. In a Canadian deployment those jobs need a floor. Nothing that supports a filed return should disappear before the retention period has run, counted from the end of the relevant tax year rather than from the date of the entry. A cleaner approach is archiving. Closed years move to cheaper storage, stay searchable, and drop out of daily screens. Deletion happens later, deliberately, and leaves its own record.

The six years can also stretch. A late-filed return, an objection or an ongoing audit can keep records relevant for longer. So the retention rule should be a setting per record type, with a hold flag that blocks deletion while a dispute is open. Hard-coding a single number into a nightly script is the mistake to avoid.

Next comes the change log. An auditor wants to see what a record said on the day it mattered and who altered it since. That rules out silent overwrites on posted transactions. Posted entries should be corrected by reversal and a new entry. Master data such as supplier bank details or price lists should keep a history of every value with a timestamp and a user. The log itself must be append-only. If an administrator can edit it, it proves very little.

Supporting documents deserve the same care. A photo of a receipt attached to an expense line is a business record. Store attachments in a format that will still open years later, keep the original file beside any compressed preview, and link each file to the transaction it supports by a stable identifier. A link that breaks when someone renames a folder turns a tidy ledger into an unsupported one.

Readable form is the part teams forget. A proprietary backup that only the current version of the system can restore is a weak answer. Plan exports that a reviewer can open without your software: ledgers and sub-ledgers as delimited files, documents in common formats, and a short data dictionary explaining each column. Test them once a year. Do it on a spare laptop, with no ERP installed.

Period locks close the loop. Once a year has been filed, lock it. Posting into a closed period should be impossible for ordinary users and logged for the few who may reopen it. Pair the lock with a simple report of every reopening, with the reason typed in. An auditor will ask. The answer is then one screen away.

Hosting location matters too. Records may sit on servers elsewhere, but they must be accessible from Canada and producible when requested. Confirm with the hosting provider that data can be exported on demand, and that access does not depend on one person abroad.

Write these rules into the specification. Then the ERP keeps the books correctly by default.