ERP Business Analyst in Ottawa

The subcontractor chain behind a federal services contract

Many Ottawa services firms deliver federal work through people who are not their employees. A department issues a call-up for a named consultant, the firm supplies an incorporated subcontractor, and money then moves in two directions: the department pays the firm against approved timesheets, and the firm pays the subcontractor, frequently only once that approval exists. When the chain lives in spreadsheets, a single rejected timesheet can leave a consultant paid for hours the client never accepted.

I map the chain end to end with the people who run it: the resourcing lead, the contract administrator and finance. The requirements cover how a timesheet is approved by the client's technical authority, how that approval releases both the client invoice and the subcontractor payable, how different buy and sell rates are held for each resource on each contract, and what happens when a consultant is replaced, a contract is extended or rates change at an option period. Margin per resource and per contract becomes a defined report rather than a month-end spreadsheet exercise.

Security status matters in this world as well, but I keep it narrow: the requirements state whether the ERP holds only a status and a review date for each consultant, or nothing at all, and your company security officer makes that call. Contract interpretation stays with your contracts team. The Canadian ERP business analyst page covers the national tax and language requirements that sit alongside these rules.

An association's annual conference, written down as a process

Many national associations headquartered in Ottawa depend on an annual conference for a meaningful part of their income. The event touches almost every corner of the ledger: registrations at member, non-member and student rates, early pricing that expires, sponsorship packages that promise logos, booths and speaking slots, exhibitor charges, hotel room blocks the association must pay for if rooms go unsold, and refunds when people cancel.

I document the conference as a process with its own calendar: when registration opens, when sponsor invoices go out, when hotel commitments can still be reduced, when the program goes to print in both languages and when final accounts are closed. Requirements follow from each step. Registration money collected before the event may need to be held as deferred revenue until the conference takes place, particularly when the dates straddle a fiscal year-end; your auditor confirms the treatment, and the system is specified to follow it. Sponsor deliverables are tracked so nothing promised is forgotten, and each sponsorship can be reported as delivered or outstanding.

Associations usually take registrations on a separate event platform, so the integration requirements matter as much as the ledger: which data moves, how often, how refunds and transfers between registrants reach finance, and who reconciles the two systems after each batch. The patterns involved are covered on the CRM and ERP integration page.

Contribution agreements: claims, advances and holdbacks

Nonprofits in the capital frequently deliver programs funded through federal contribution agreements. These agreements read like small accounting manuals. They list eligible cost categories, set claim periods, allow or forbid moving money between budget lines, define how advances are paid and reconciled, and may hold back part of the final payment until a closing report is accepted. Some also ask the recipient to declare other government assistance received for the same project.

A ledger organized only by department and account rarely produces a claim without a great deal of manual work. I read each agreement with your finance and program staff and translate it into requirements: a project or funding dimension that every relevant transaction carries, a mapping from your chart of accounts to the agreement's cost categories, rules for allocating shared costs such as rent or salaries, a record of advances received and offset, and a claim report in the funder's layout with supporting documents attached.

I do not interpret the agreement on the funder's behalf. Where wording is ambiguous, the question goes to your program officer, and the accounting treatment is confirmed by your auditor before the requirement is finalized. Testing then rebuilds a real past claim in the new system and compares it line by line with what was submitted. The project costing page shows the underlying structure.

Loaner units and evaluations in Kanata product firms

Technology firms in Kanata and across the city often let prospects try before they buy. An evaluation unit goes to a government lab for testing, a demo kit travels to a trade show, a loaner replaces a customer's failed device while the original is repaired. Each of those units is company property sitting outside the warehouse, and it is easy to lose sight of which ones are where, how long they have been away and whether they are coming back.

The requirements I write for this cover the loan itself, the life of the unit and the accounting consequences. A loan needs an approval, an agreement, a named borrower, an expected return date and a serial number. While the unit is out, the system should show it at the borrower's location, flag loans past their return date and let sales see open evaluations to follow up. When the unit comes back, it is inspected and returned to stock, refurbished or written down. If the borrower keeps it, the loan converts to a sale at an agreed price, and the requirement states exactly how that conversion is recorded.

Whether demo units are carried as inventory or as fixed assets, and how their value declines, is for your accountant to decide; the requirement records that decision so each platform can be tested against it. Questions about sending units abroad stay with your trade compliance advisor. The inventory and warehousing page covers the stock side in more depth.

Remote workshops and the documents you keep

The analysis runs remotely, with visits to Ottawa by arrangement when a workshop genuinely needs everyone together. Before each session I ask for the documents that set the rules, which here are often a contract, a funding agreement or a venue contract, with anything sensitive removed first. Workshops stay focused on one process at a time, and a written summary follows each one so that anyone who missed it can correct the record.

The engagement runs in English. If program staff or members work mainly in French, a bilingual colleague on your side can lead those conversations while I frame the questions and capture the answers. Any French wording destined for the requirements or templates is drafted by a native French speaker, whether a colleague of yours or someone at a local partner, who also signs it off.

What you keep at the end: process maps for each workflow, a numbered requirement document with owners and priorities, a fit-gap matrix for the shortlisted platforms, a log of open questions for your advisors, and test scripts built from your own paperwork. If protected information is involved, the work is arranged so it stays with your screened staff, as the Ottawa freelance ERP page explains. For platform and sector context, see the Ottawa ERP consultant page and my ERP business analysis service.