Canada GST/HST for Platform Fees: How Marketplaces Decide What to Charge, Track, and Report

Document who charges, tracks, and reports GST/HST#

You can make defensible calls on canada gst hst platform fees without building a large tax operations function, but only if your controls are explicit and documented. The core questions are straightforward: who is making the supply, what is being charged, which rate applies, and what evidence supports that treatment.

Marketplaces make this harder because different teams need different things at the same time: simple checkout behavior, clean reporting, and a position that still holds if the facts change. The source set here does not support a blanket rule for every platform model. It does confirm that rate selection is a real decision. GST is identified at 5%, and HST at 13% and 15%.

This article focuses on a practical control sequence for four jobs:

• what to charge
• what to track
• what to report
• when to escalate instead of guessing

Use a simple gating rule: if your invoice logic cannot point to a named source and review date, do not automate it broadly. In the provided sources, CRA states digital economy GST/HST measures are in effect as of July 1, 2021, and that CRA page shows a last-modified date of 2025-10-22. Record those details in your determination log so historical decisions remain explainable.

There is also a concrete setup risk in the simplified-regime scenario described. A valid GST/HST registration number can affect whether GST/HST is collected, and incorrect account treatment can leave a business paying tax it cannot recover through ITCs. Before you handle edge cases, make sure billing and account profiles can capture that registration status wherever your treatment depends on it.

Scope here is intentionally narrow. This section relies only on supported signals in the sources: digital economy rules are in force, non-resident and simplified-regime mechanics exist, and registration status can matter operationally. It does not assume all marketplace fees are taxed the same way, and it does not treat these excerpts as fully resolving every platform-fee model. Where guidance is narrower, including secondary-source B2C framing for non-resident digital supplies, treat that as a review trigger rather than a reason to improvise.

Start with the terms that drive every decision#

Use precise terms first, or your charging and reporting logic will drift.

GST/HST is the federal regime: required registrants charge and collect tax on taxable supplies made in Canada. PST may sit outside that system depending on province and facts, so do not collapse everything into one generic "sales tax" label.

For GST/HST outcomes, treat place of supply as a control input, not a formality. It determines whether the supply is made in Canada and which province's rate applies. If a rule or ticket cannot state the taxable supply and the place-of-supply assumption, do not automate it.

Use role labels consistently in operations:

• Non-resident vendor: non-resident supplier of digital goods or services over online channels.
• Non-resident digital platform operator: keep this as a scoped role label under digital-economy platform fact patterns. Do not treat these excerpts as a complete CRA definition.
• Accommodation platform operator: explicitly covered in the CRA material for platform-based short-term accommodation.

Reuse the same decision primitives in every memo, ticket, and review: taxable supply, place of supply, and GST/HST registration number status. Registration status can change who is expected to charge in some flows, even though these excerpts do not provide number format or validation method.

One known unknown should stay visible throughout: the primary guidance here is explicit for platform-based short-term accommodation, but broader platform-fee treatment outside that lane is not fully resolved in the provided sources.

Decide who charges first before you touch rates#

If you cannot state who is expected to charge GST/HST on a line item, do not choose a rate yet. For platform fees, liability assignment comes before tax calculation.

That order matters because regime choice and registration status change what you need to test. Secondary guidance says you should determine the applicable regime before registration, and it frames the choice as an economic tradeoff: the regular regime is described as allowing recovery of GST paid at the border and on Canadian expenses, while the simplified regime is described as pay-only, with that tax treated as non-recoverable.

Build a scenario table that shows confidence, not false certainty#

Do not force a full supplier-versus-platform rule set from incomplete authority. Use a table that separates confirmed inputs, provisional signals, and escalation cases.

Use a hard stop when supplier versus platform responsibility is unclear#

Make this a policy rule: if supplier-versus-platform responsibility is unclear, pause invoice automation and open tax or legal review before charging.

That stop avoids correction work and filing risk later. Secondary guidance also highlights potential late-filing exposure of 1% of tax owing plus 0.25% monthly, up to 12 months, and a $250 penalty for ignoring a CRA demand. Use those as risk signals, not as legal authority.

Separate CRA authority from secondary signals#

Use CRA RC4022, especially "Who charges the GST/HST," as the primary checkpoint for liability review. But RC4022 also states it uses plain language and does not replace the law, so unresolved edge cases still need escalation.

Treat simplified-versus-regular descriptions and the 9-digit BN B2B signal as secondary operator inputs. They help you branch flows under digital economy GST/HST measures, but they are not enough on their own to assign charging responsibility on disputed platform fees.

Add one audit-grade checkpoint to every determination#

Every liability determination should record:

• exact source used, including revision marker where available, for example RC4022(E) Rev. 25
• source URL and date reviewed
• fact pattern summary: supplier status, platform regime, and recipient registration status
• unresolved assumptions and escalation owner

If your team cannot show the exact source and review date used for a decision under the digital economy GST/HST measures, that scenario is not ready for full automation.

Separate the underlying sale from the platform fee#

Start by treating the underlying sale and the platform fee as separate line-item decisions. In the CRA qualifying-goods guidance, treatment depends on whether the sale is direct or platform-facilitated, and on vendor registration status under the normal regime. That same guidance states that in the non-registered-vendor qualifying-goods flow, the operator is not required to charge and collect GST/HST on platform services.

If your billing includes both a marketplace sale and a distinct platform fee, do not let one line inherit the other line's treatment by default. The payout-side version of the same control problem shows up when teams net commission logic into seller settlements, which we unpack in Deduct Platform Commission Before Seller Payouts in Marketplaces.

Use one billing rule throughout: if a fee is billed as a distinct platform service, test it separately from the underlying supply, even when it is percentage-based or netted from payout.

The common failure mode is one tax flag across all lines. That is efficient in the system, but weak in an audit when the fee's character differs from the core sale. Your file should show, by line, the contract language, invoice presentation, recipient type, and authority reviewed.

Keep the scope tight as you do this. CRA plain-language pages are informational and do not replace the law, and older interpretation letters may not reflect current CRA position. Use those materials as guidance inputs, then escalate unresolved line-item classifications instead of forcing a single order-level rule.

Apply place of supply correctly before invoicing#

Do not apply a flat Canada-wide GST/HST rate to platform fees. Rate outcomes depend on place-of-supply rules and the facts of the supply, and the result can range from 5% GST to 15% HST across provinces.

The practical impact is material. The provided examples show 13% HST for a Toronto invoice versus 5% GST for a Calgary invoice, a $500 difference on a $5,000 invoice. If the rate is wrong, you either undercharge and carry exposure, or you issue corrections later.

Start with supply type, then apply the right province signal#

The province test should follow the supply type. For many services, use recipient location as the starting point, with the client billing address as a practical checkpoint. In that context, supplier location is not the main rate driver.

Do not assume a separately billed platform fee always follows the same province logic as the underlying goods line. For goods, the destination principle points to where the buyer takes possession. For services performed at a specific physical location, place of supply follows where the work is physically performed. One order can therefore produce different province outcomes across lines.

Validate and document before production use#

Before rollout, validate your mapping logic against current CRA guidance and keep the rule path documented for each scenario you support. For mixed models, keep clear records of inputs, selected province, output rate, source reviewed, and review date so line-level differences remain explainable.

Treat tax-rate mappings as controlled configuration, with version history and accountable ownership, so jurisdiction changes can be traced later.

Keep the legal hierarchy explicit in your process. CRA RC4022 is operational guidance and does not replace the law, and legislative interpretation points back to the Excise Tax Act. Automate common cases, and escalate unclear edge cases instead of forcing one province rule across every fee line.

Handle B2B and B2C flows without overclaiming certainty#

Keep B2B and B2C as separate paths, but treat platform-fee treatment as unresolved unless you can point to primary Canada Revenue Agency support for the exact scenario.

Use a customer-provided GST/HST registration number as a review input, not automatic proof that tax treatment should change. In policy text and code comments, state what that field does and does not control, and who approved the rule.

Treat any simplified GST/HST regime signal as provisional in this context. The provided materials do not establish platform-fee B2B or B2C mechanics or input tax credit outcomes, so apply an explicit rule: if a B2B branch depends on non-primary guidance, label it provisional and require scheduled revalidation against updated CRA publications.

At minimum, keep a decision record for each customer-status branch:

• status data captured from the customer, including the registration number as provided
• legal entity and billing details used for invoicing
• capture or update date
• source reviewed, approver, and review date
• exception note when a non-default path is allowed

If you cannot explain the treatment decision from that record, route the case to manual review and use your documented default path until you validate it.

Cover cross-border and exception scenarios explicitly#

Once you have domestic B2B and B2C paths defined, add a separate cross-border branch. For Canada GST/HST on platform fees, start by identifying whether the case involves a non-resident vendor, a non-resident digital platform operator, or both, and which entity is making or facilitating the supply. The CRA's cross-border digital-economy guidance is useful for scoping that branch, but it still does not replace your line-item fee classification. If your team manages multiple marketplace tax regimes, compare this Canada-specific branch with the Global VAT Compliance Map for Digital Services Platform Operators so cross-border rules stay separate from local fee treatment.

Keep this branch tied to primary law. CRA guide RC4027(E) Rev.23 is useful for resident and non-resident analysis, but it is informational and does not replace the law. In your decision record, note the guide version used and the legal baseline used for the rule, Excise Tax Act and/or GST/HST Regulations.

In the decision tree, separate at least these two cross-border digital patterns:

• non-resident vendor supplying digital products or services to consumers in Canada
• digital platform operator facilitating those supplies

Treat the November 30, 2020 digital-economy proposal context and Fall Economic Statement, Annex 4 as research checkpoints, not proof of current law. If your team cannot point to a current primary source for the charging rule, keep the branch out of production logic.

Do not generalize one flow across all others. Some mailed or couriered tangible goods scenarios can differ from digital supply treatment, so keep physical-fulfillment lines separate from digital-services analysis and from platform-fee analysis.

Also keep adjacent regimes separate from GST/HST charging decisions:

• reverse charge mechanism analysis does not decide whether your entity should charge GST/HST
• digital services tax discussions do not override GST/HST charging logic

Trigger counsel before checkout logic gets too clever#

Require a short legal memo before launch when one checkout spans multiple supply types or jurisdictions. Trigger this when you see:

The memo should identify the parties, each supply line, the invoicing entity, and the source behind each conclusion. Do not treat an EOR or multi-entity billing structure alone as proof that tax characterization is settled. These setups can carry legal, tax, and regulatory risk that is not obvious at first glance.

If non-resident status, entity role, and supply type have not each been tested, route the scenario to manual review before automation.

Build the minimum evidence pack auditors and controllers will ask for#

Make every GST/HST decision explainable after the fact. If you cannot show the contract terms, invoice specimen, tax determination log, source version, and approval trail, the control will not hold at month end or in an audit.

Define the evidence pack by transaction class so analysts are not inventing records case by case. If you also run multi-country digital tax programs, keep that record model compatible with our global VAT compliance map for platform operators.

Keep source tracking explicit. RC4022 and RC4027 are useful plain-language guidance, but they do not replace the law, so log both the guide version consulted, such as RC4022(E) Rev. 25 or RC4027(E) Rev.23, and the controlling legal authority.

Tie each tax call to an operational owner#

Every determination needs an owner in operations. Map it to an approval owner, a change ticket for billing and tax configuration, and a reconciliation reference in the ledger. That linkage lets controllers verify that the invoice specimen, tax code, and booked GST/HST treatment all reflect the same decision.

After release, sample one live invoice per scenario and confirm three things match: contract fee description, invoice line naming, and ledger tax treatment. When product changes invoice lines or bundles fees but tax logic is not updated, teams create risk for double taxation, unintended non-taxation, and penalties.

Capture the fields that settle disputes quickly#

Capture the inputs that drove the result, at minimum:

These fields keep later reviews evidence-based instead of forcing the team to reconstruct assumptions.

Keep old decisions readable after rules or configs change#

Set a retention standard that preserves original decisions and each revision, with effective dates. Do not overwrite prior logic when rule tables, contracts, or checkout flows change.

Keep the old invoice specimen, prior source-version note, and superseding approval together so historical invoices remain explainable after updates. If you cannot reconstruct why a prior platform-fee treatment was applied under the place-of-supply logic used at that time, you have a control gap.

Turn policy into month-end controls your team can run#

At month end, your control should prove that each GST/HST outcome on platform-fee lines can be traced to documented logic, not just to a clean total.

Use a recurring checklist your team can run every close:

• rate-table review against approved place-of-supply logic
• sample invoice QA
• exception backlog review
• unresolved escalation aging

For invoice QA, do more than confirm that tax was charged. Confirm that the province input, invoice line naming, tax code, and reporting extract all align to the same supply treatment.

Reconcile by scenario bucket, not only by grand total, because totals can hide classification errors on platform-fee lines. At minimum, split into standard platform fee, cross-border or non-resident case, and manual override or exception. If you automate tax calculation, compare each bucket against the controls in our automated tax collection guide before you trust the close checklist. In each bucket, match:

• GST/HST charged on invoices
• the reporting extract used for filing
• the accounting entry posted to the liability account

This follows the same control principle as daily POS reconciliation: match operational output to accounting records rather than trusting one report.

Use one explicit internal failure rule: if a scenario cannot be reconciled to documented logic within one close cycle, freeze rollout expansion for that flow until the mismatch is resolved. This is an operational guardrail, not a legal requirement.

Keep unresolved items audit-ready. The CRA may ask for supporting documentation, and the claimant must establish that statutory conditions are met. For any failed bucket, the reviewer should be able to pull the invoice specimen, tax determination log, source version, approval owner, and the exact fact inputs used, especially province and any registration-status field. If the explanation relies only on RC4022, treat that as escalation, since the guide does not replace the law.

Know when to escalate instead of guessing#

Escalate when your GST/HST position depends on interpretation gaps, not clear CRA support. For platform fees, unresolved classification assumptions can turn into long disputes if CRA later assesses differently.

Open tax or legal review when any of these are true:

• your fee could reasonably be treated as either a separate platform service or part of the underlying supply, especially outside platform-based short-term accommodation
• your product or finance design relies on a treatment not directly stated in current Canada Revenue Agency text
• one checkout combines digital services, physical fulfillment, and billing across more than one entity

Treat phrases like "should follow" or "CRA would likely view" as a stop signal for automation. Accommodation guidance may be more explicit in your materials, but that does not automatically extend to every marketplace fee model.

Build an escalation pack that lets tax or counsel classify the fee without re-interviewing the business:

• contract clause for the fee
• invoice specimen with each line item
• checkout and billing flow by entity
• merchant-of-record assignment
• any customer GST/HST registration capture fields
• exact place-of-supply inputs used by your logic
• verification that the invoicing legal entity matches the entity assumed in your tax logic

A common failure mode is silent drift between registration fields, tax display, and collection logic. In one public host report, after sharing HST registration details with a platform, the host said taxes were "not showing" and raised concern about a 13% hit. That is not legal authority, but it is a practical warning sign.

Escalate early when objection risk is plausible. Reported CRA GST/HST objection timing for January 2026 was 145 days for low complexity, 268 days for medium, and over 500 days for high, and those averages can hide variance and exclude time waiting on taxpayer information. If a position could lead to a Notice of Objection, lock down the facts before launch.

Implement this in your payments stack with traceable controls#

Once you set the escalation rules, make each tax decision reproducible from records. For platform fees, store the facts used at invoice time, the treatment applied, and any later correction so finance can explain outcomes without rebuilding the story from raw events.

Turn policy into a decision service#

Keep tax logic in one decision layer instead of splitting it across checkout, payouts, and manual overrides. Capture the decision inputs, the outcome, when it was made, and which invoice or charge it applied to.

When a correction is needed, recalculate from the recorded decision context plus the corrected facts. A practical check is simple: for one posted invoice, confirm you can show what facts were used, what decision was made, and what changed after any correction.

Make the ledger and payout trail line up#

A tax decision is not complete until invoice, ledger, and payout records agree. If those records diverge, you create both an audit gap and a close problem.

Use clear exception states for unresolved treatment instead of forcing uncertain cases into posted status. This is where automation helps most: better invoice validation and fewer approval or payment bottlenecks, not cleaner-looking totals that hide uncertainty.

Design retries so they do not duplicate tax#

For API-first flows, treat retries as a control point. Use stable decision identifiers and audit events so repeated requests return the same tax result unless the underlying facts actually changed.

The failure mode to prevent is duplicate tax posting during retries or event replays. When that happens, teams lose trust in the subledger even if the invoice UI looks correct.

Keep the evidence file and the user message tight#

Assume scrutiny and keep a consistent, well-organized evidence file for review. The file should let your team respond with facts, not assumptions, when a decision is challenged.

Keep UI and help text precise: treatment is based on information available at invoicing and may require review where coverage varies. That will not fix a weak position, but it reduces avoidable confusion when a charge needs correction.

Conclusion#

For canada gst hst platform fees, the sequence is the control: confirm who must charge, classify the fee, apply place-of-supply logic for the rate, then push that result into invoicing and reporting controls. If rate debates start before role and liability are settled, the order is already wrong.

CRA guidance in this area is input-driven. It turns on whether supplies are made directly or through a distribution platform, whether the party is in the simplified or normal GST/HST regime, and whether the supply is a taxable supply made in Canada. Those inputs determine who charges, whether GST/HST applies, and which province drives the rate outcome.

Keep the control set small enough to audit on live invoices:

• role and liability
• registration path
• supply classification
• place-of-supply input
• customer status where relevant
• decision source and review date

If any required field is missing, treat the invoice decision as incomplete rather than final.

Your practical next step is one internal gap review of live invoice flows. For each high-volume scenario, document who charges, how the fee is classified, which place-of-supply data is used, and what support backs the decision, then list every scenario that still depends on assumptions. If your operators already maintain a broader reporting calendar, pair that review with EU Marketplace DAC7 Reporting Deadlines by Month so tax-control deadlines do not drift across teams. A narrow, traceable control set will hold up better than broad policy language that cannot be tested on real transactions.