ERP Requirements Consultant, Canada

What a Canadian ERP specification is made of

The document I produce for Canadian companies has two halves. The first is functional and follows how work moves through the business: selling and billing, buying and paying, stock and warehousing, production or project delivery, then period-end close and reporting. The second covers what cuts across all areas: statutory lines, language, currencies, security, hosting, interfaces and data migration.

Each requirement carries the same fields, which is what makes it usable later:

• A unique ID and the process area it belongs to.
• One clear statement of behavior.
• A MoSCoW priority agreed with the area owner.
• An acceptance condition describing the evidence a tester will look for.
• The business owner and, where relevant, the advisor who confirmed it.

I explain priorities in workshops in plain language rather than by quota. Must means you cannot invoice, pay, file or comply without it. Should means a manual route exists but is costly or error-prone. Could means helpful if the platform offers it in standard. Won't means consciously deferred, which matters in Canada because provincial and language items have a habit of being postponed and then rediscovered during testing.

For how the underlying requirements are captured in workshops, see ERP requirements gathering; the ERP business analyst for Canada page covers process mapping and fit-gap in depth.

Sales tax, payroll and retention lines for Canada

Statutory lines must be specific enough to fail a test. I draft them, then your accountant or tax advisor confirms or corrects each one; I do not decide how GST/HST, PST or QST apply to your transactions.

• Tax determination. The system must determine the province of supply from defined address fields and apply the tax combination your advisor specifies, including cases where GST, PST or QST are charged separately.
• Exemptions and registrations. Customer and supplier exemption status, registration numbers stored and printed where required, and checks on missing numbers.
• Return support. Reports that separate tax collected and input tax credits or refunds by tax type, with drill-down to transactions.
• Payroll interface. Many Canadian businesses keep payroll with a provider that handles source deductions, year-end slips and records of employment. The specification defines the journal coming back: format, frequency, split by entity, province and department, and who reconciles it.
• Retention. How long books and records stay retrievable, based on the guidance your accountant gives, and how closed periods are locked.

E-invoicing in Canada has largely been driven by customers through EDI and supplier portals rather than by a general mandate. I still add a readiness line on structured invoice formats, so the platform's options are known before signature. Currency lines cover CAD as functional currency, USD pricing and bank accounts, revaluation and how US customers see their documents.

French and bilingual output requirements

If you sell to customers in Quebec, employ staff there or ship products into the province, French-language obligations affect what the ERP must produce. The scope of those obligations is a legal question for your Quebec counsel; the specification turns their answer into concrete lines.

I write language requirements as an inventory of outputs rather than a general statement such as "must support French":

• Customer documents. Quotes, order confirmations, invoices, credit notes and statements, each marked French, bilingual or English, with the rule that selects the version.
• Product and packaging data. Item descriptions, labels and any printed notices that need French text, and where that text is maintained.
• Employee-facing material. Screens, procedures and training content for Quebec staff, if counsel advises it.
• Text ownership. Who writes and checks each French template. The engagement runs in English; French wording is written or checked by bilingual people on your team or a translation partner.

Each line gets an acceptance condition, for example that a test customer flagged as French receives the French invoice template with all fixed text translated. That gives vendors something precise to demonstrate and gives testers something they can check without debate.

Hosting, access, interfaces and data migration

Lines about behavior rather than function get vague answers unless they are framed as direct questions, so each vendor responds to these in writing:

• Data location. Where production data and backups sit, whether a Canadian region is available and whether any customer contract, public sector work or internal policy requires it.
• Privacy. How the vendor supports obligations under federal and provincial privacy laws, including Quebec's private-sector privacy law, as your counsel interprets them.
• Access and audit. Single sign-on, roles by company and site, removal of leavers, and field-level change history on financial and master data.
• Availability. Support hours and system performance across Newfoundland to Pacific time, and during month-end and seasonal peaks.

Interfaces get one card each: systems, direction, trigger, frequency, owner and failure handling. A Canadian list often includes bank and EFT payment files, payroll journals, EDI with retailers, eCommerce orders, US entities or warehouses and a reporting tool.

Migration requirements specify which objects move from QuickBooks, Sage, Acomba or another system, how much history comes across, who cleans customers, suppliers and items, and how opening balances, open tax periods and USD accounts are reconciled and signed off before go-live.

Traceability, tenders, version control and common gaps

Requirement IDs should appear in every later artifact. I keep a register in which each line links to the demo script step where vendors must show it, the fit-gap result per platform and the UAT case that will close it. The Canadian ERP selection page explains how demos built from those scripts are scored, and ERP RFP consulting covers the annex vendors respond to line by line. When the contract is drafted, the partner's scope can point to a named version of the document, which keeps delivery and acceptance anchored to identical wording.

After baseline, nothing changes silently. Each edit gets a change log entry with the reason, the approver and the tests affected, and the version number moves on. Sign-off happens area by area, then once more at sponsor level for the full baseline.

Omissions that expose a Canadian project to risk include:

• Sales tax written as one line, with no rule for province of supply.
• French outputs left for later, then found during UAT.
• USD treated as an afterthought, missing bank, pricing and revaluation needs.
• Payroll postings unspecified, so the first close stalls on reconciliation.

Workshops run remotely in Canadian business hours, and a site visit can be added by arrangement. I accept nothing from vendors or partners, whether commission or referral fee. For wider advisory topics, read about ERP consulting in Canada or start from the Canadian market overview.