Before you switch
Bring your last pay stub.
Your current provider already produced one. It is what your employee actually received, and what the CRA already holds remittances against. Put its figures in below and Momiji will recompute the same period and show you every line beside theirs. If it does not tie to the cent, you do not go live.
The tie-out calculator
The comparison appears here. Nothing is sent anywhere: the engine runs in this browser tab, and it stops the moment you close it.
Nothing you type here reaches us.
A salary and a pay stub are about as personal as a business figure gets, so this calculator does not send them anywhere. The payroll engine is loaded into this page and runs on your own machine. There is no request to intercept, no server log to purge and no record to ask us to delete, because the numbers never leave the tab. Close it and they are gone.
We record that the calculator was used, and nothing else about it. Not the province, not the figures, not the result.
Read this beside the answer
What a tie proves, and what it does not.
A proof that overstates itself is a sales trick. These are the four things worth knowing before you read whatever the table above says.
- 01
A break is the valuable outcome
It means one of two things, and either is cheaper to find now. The setup entered here is wrong, a claim code or an opening balance or a pay frequency, and the fix is an edit rather than an amended remittance. Or the figure being paid was wrong, which somebody would otherwise keep paying. So this is not a promise that it will match. It is a promise that you will know, either way, before it matters.
- 02
What it does not prove
It proves that one period reproduces from the details you gave. It is not a guarantee about every future scenario, and it is only as good as those details: a taxable benefit, a pension deduction or a bonus in that period will move the answer and there is nowhere here to enter one. The signed-in version reads your real setup and your real opening balances instead of asking you to retype them.
- 03
The provinces we refuse
Manitoba is not tied out here at all. Its basic personal amount falls away as income rises, to zero, and our figure is confirmed against the CRA at one income inside that range but not at the points where it starts, ends and bottoms out. We block live runs there for the same reason. Quebec is a separate regime altogether, Revenu Quebec rather than the CRA, with its own pension and parental insurance contributions, and the engine refuses it by design rather than guessing.
- 04
Where the arithmetic comes from
The same engine the product runs, byte for byte, from the same file. It is replayed on every build against 55 cases and 321 fields, 238 of them anchored to figures the CRA either published in its payroll guides or returned from its own online calculator, with no mismatches. The check that guards it is what found a rounding bug in our own basic-personal-amount taper.
Then do it properly
The version inside Momiji reads your real setup and your real opening balances rather than asking you to retype them, runs the whole roster instead of one person, and is the gate on going live: the first pay run will not commit until a period has tied out, or the organization owner has recorded an override with a reason that stays on the run. Setting a migration up, including capturing and validating those opening balances, is what the one-time fee on the pricing page pays for.
How the engine is checked, and the defect that checking found in it, is set out under Proof. The rest of what the payroll module does is under Payroll. If you want somebody to walk a stub through with you, write to hello@mymomiji.com.