ERP Business Analyst, Canada

Translating Canadian sales tax into system requirements

Sales tax is where many Canadian ERP projects get stuck. Depending on the province, a sale may attract GST alone, HST, or GST with a separate provincial tax such as PST or Quebec's QST. Treatment can vary by product or service, by customer type and by where the goods or services are delivered. Businesses also need to track input tax credits and the equivalent Quebec refunds correctly.

Rather than writing a single line such as "system must handle Canadian taxes," I build a tax scenario matrix as part of the BRD. Each row describes a real situation, for example a product shipped from Ontario to a customer in British Columbia, a service delivered to a Quebec client, or an exempt customer with a certificate on file. Your accountant confirms the correct treatment, and the matrix becomes both a configuration guide and a set of test cases.

I also capture reporting requirements: what your finance team needs to prepare GST/HST, QST and provincial returns, and what audit trail the CRA or provincial authorities may expect. I do not give tax advice. My role is to make sure the confirmed rules are documented, configurable and testable. This work sits within my ERP requirements gathering service.

Process mapping for cross-border and multi-site operations

Many Canadian companies buy from US suppliers, sell into US markets, or run warehouses in more than one province. These operations add steps that are easy to miss until a process map makes them visible.

When I map processes for Canadian clients, I look closely at:

• Purchasing in USD: how purchase orders, supplier invoices and payments are handled, and when exchange rates are fixed.
• Landed cost: how freight, duties and broker fees are captured and allocated to inventory.
• Sales in two currencies: price lists, customer accounts and bank accounts in CAD and USD, and how revaluation is handled at month-end.
• Inter-warehouse transfers: stock movements between provinces and the tax and costing effects.
• Seasonal patterns: sectors such as construction and agriculture where volumes change sharply through the year.

The maps show who does each step, which system is used and where data is re-keyed. They become the basis for to-be process design, where we decide what the ERP should automate and what stays manual. My ERP process mapping page explains the method in more detail.

Capturing French-language and Quebec requirements

If you sell to customers in Quebec or employ French-speaking staff, language needs should be written into requirements from the start, not discovered during testing. Quebec has its own rules on the use of French in commerce and the workplace, and your legal advisors should confirm what applies to your business. My job is to make sure the system can meet those confirmed needs.

In the BRD, I specify requirements such as:

• Which customer-facing documents must be available in French or bilingually, including invoices, quotations, order confirmations and statements.
• Whether product names, descriptions and labels need French versions, and where that data is maintained.
• Whether users need a French interface, and which roles that applies to.
• How customer language preference is stored and used to select templates and email communications.

Platforms differ in how well they support translated master data, bilingual templates and French user interfaces. These requirements are scored in the fit-gap analysis like any other, so language support influences the platform decision rather than becoming a late surprise. My BRD consulting page shows how I structure these sections.

Requirements for moving off QuickBooks or Sage

Many Canadian ERP projects begin as a migration from QuickBooks, Sage or a similar accounting system. Business analysis is what turns that migration from a data dump into a controlled change.

I start by documenting what the current system actually does, including the reports finance relies on, the custom fields that carry meaning, and the spreadsheets that fill gaps. Then I define requirements for the new system and a mapping for each data set:

• Chart of accounts, redesigned where needed for departments, locations or projects.
• Customers and vendors, including tax registration details, currencies and payment terms.
• Items, units of measure, costing methods and opening inventory.
• Sales tax codes mapped to the new tax configuration.
• Open receivables and payables, and how much history to bring across.

I also agree a cut-over approach, typically at a period end, and list reconciliation checks so finance can prove opening balances match. The ERP migration checklist covers the broader steps, and my ERP consultant page for Canada explains when moving to a full ERP makes sense.

Fit-gap analysis and UAT built from Canadian scenarios

With requirements agreed, I score each shortlisted platform in a fit-gap matrix. Each requirement is marked as met by standard features, configuration, an add-on, a workaround or custom development, with notes on effort and risk. For Canadian projects, the sales tax matrix, multi-currency handling and French-language support usually carry the most weight, because gaps there are expensive to work around later.

The same requirements drive user acceptance testing. I write UAT scripts that use your real scenarios: an HST sale in Ontario, a GST and PST sale in another province, a QST sale to a Quebec customer, a USD purchase with landed cost, a credit note, a month-end revaluation, and so on. Each script has expected results agreed in advance with finance.

I support test cycles remotely, scheduled across your time zones, and track defects until they are resolved. At the end, you have evidence that the system meets the signed-off requirements, which is useful for management approval and for your external accountant. See my ERP gap analysis and testing and UAT pages, visit the Canada overview, or contact me to discuss your project.