An accountant at a seafood processor walked us through a stack of purchase invoices that barely looked related to one another. Fisherman tickets sat beside processor packs. Freight add-ons arrived wrapped in pages of notes that were not the bill. A mid market operation with real volume going out by wire and EFT, and enough of it that a bad coding habit compounds before anyone has time for a post mortem.
They did not ask for smarter OCR. They asked whether they could type a rule. Anytime the system identifies PST, code that balance into the same account as the product on the invoice.
That is the short answer. Provincial sales tax on many Canadian product invoices is not a freestanding tax expense in the GL the way teams treat recoverable GST/HST. It often belongs with the goods. Capture can read the letters P-S-T. Coding still has to know what your books do with the dollars.
Who this applies to: teams that buy tangible goods in PST provinces (or from vendors who charge PST), where finance already folds PST into the product or inventory account, and where invoice layouts change often enough that template training never sticks.
Reading the tax line is not the same as booking it
The first problem looks solved the moment a tool highlights a PST amount. Finance celebrates. Then the trial balance disagrees with how inventory is supposed to carry cost.
GST/HST and PST are not the same animal. The Canada Revenue Agency administers GST/HST and lets registrants recover eligible amounts as input tax credits when the purchase supports commercial activity. Provincial sales tax in places such as British Columbia, Saskatchewan, and Manitoba is a separate levy, run by the province. Public corporate tax summaries, including PwC's Canada other taxes overview, repeat what controllers already practice: PST is generally not recoverable the way GST is. It sits in cost of goods or in the inventory or expense account your team chose for that product.
So if an AP tool parks PST in a generic tax bucket because that is how a US template was drawn, you get a clean extract and a dirty book. Someone reclassifies later. Or the variance hides until inventory rolls and margin looks wrong for reasons nobody connects to last Tuesday's invoice.
That first "AI coded it" win exposes something harder. If the model learns only from whatever users typed last month, dirty history becomes the training set. The seafood accountant said it plainly: rely on everything a user puts in and the machine works off messy data. They wanted an explicit rule they could see and edit. Not a black box that remembered yesterday's shortcuts and called it intelligence.
Messy documents make both problems worse. Their invoices looked wildly different from one another. Some were loaded with information unrelated to the payable itself. A system that only trusts layout similarity will keep rediscovering the wrong home for PST every time the vendor redesigns a packing note.
What exception rates tell you about "almost right" coding
This is not a niche annoyance reserved for seafood. Ardent Partners’ State of ePayables 2024 puts the average invoice exception rate at 14.0%. Tax and coding mismatches are classic exception fuel. The document was "read." The ERP still rejects it, or finance still reworks it after a false green check.
You do not need a manufactured ROI story to feel that cost. You need fewer bills that look posted and are not. Measure your own reclass journal entries that exist only to move PST out of a tax account and onto product. That count is the local benchmark.
The decision underneath the feature
We put plain language extraction and coding instructions on the vendor, including whole document rules you can author while you are looking at a real invoice. For the seafood team, the instruction was the sentence they already used when training new clerks: when PST appears, put that balance on the same GL as the product line. They wrote it once. It applies to every invoice that vendor sends afterwards, however the layout changes.
That choice rejects two common product paths.
First, "learn only from historical coding." History is useful as a hint and as a resemblance flag. It is a poor sole source of truth when the team already knows the history is inconsistent.
Second, "always treat tax as tax." Canadian product invoices break that shorthand. PST treatment is a finance policy, not a layout fact. The system should take the policy as written English on the vendor, then apply it the next time that vendor’s PDF arrives looking completely different.
Vendor profiles carry extraction rules with whole document and by field instructions. Invoice lines support tax breakdowns. Collaboration comments sit on fields so a reviewer can challenge a coding choice without rebuilding the email thread. Where a field was filled by resemblance to past invoices rather than by an explicit rule, Finofo marks it, so the reviewer knows which lines earned a second look. Finofo does the verification. Your team keeps the judgment.
The reason a rule like this holds is that there is one engine to hold it. Finofo is the only Canadian built, AI native platform that brings accounts payable, expense management and purchasing together, on the cards, bank and ERP a business already uses. A PST instruction written on a vendor applies whether that vendor’s charges arrive as an invoice, on a card statement, or against a purchase order. Canadian tax is a data model in Finofo, not a checkbox added to software drawn for another country.
A ten-invoice diagnostic you can run without buying anything
Pull ten recent invoices that include PST or RST. For each, answer three questions in a shared sheet.
If more than a couple fail the first row, you have a policy-encoding problem, not an OCR accuracy problem. Spend the next evaluation hour on rule authorship, not on vendor claims about character error rates.
Ask product evaluators one blunt question in writing: can finance write "anytime PST, code to the product account" and see that instruction stick to the vendor profile, or does the tool only learn silently from prior posts?
Also ask what happens when two product lines on one invoice carry different accounts. If the rule cannot say "same account as the related product line," you will still be hand-allocating the PST strip.
Finofo is the only Canadian built, AI native platform that brings accounts payable, expense management and purchasing together, on the cards, bank and ERP a business already uses. The behaviour described above is one engine doing one job across vendor invoices, employee expenses and purchase orders, not three tools stitched together.
What stays with your team
Finofo is designed so that the people who sign off on the numbers stay in control of them. A few things are deliberately yours.
Your PST policy is written by your team, in your words. Finofo does not invent a GL treatment from thin air, because the right treatment for seafood inventory versus office supplies is a decision your finance team already made. The system's job is to apply that decision every time, exactly as written, and to show you which fields it filled by rule and which by resemblance.
Review remains a real step on noisy packs. Fisherman tickets and overloaded PDFs get extracted at line level, and the math is checked, and a reviewer still sees the result before it posts. Extraction rules remove the rekeying. The sign off stays where it belongs.
And the booking rule is yours to define, not tax advice from us. How your entity recovers GST/HST, how you treat partially exempt activity, and how provinces define taxable services are questions for your tax advisor. Finofo encodes the rule you already believe is correct and applies it consistently.
Frequently asked questions
Does this replace our ERP tax groups?
No. ERP tax groups, recoverable flags and entity defaults still have to exist. The point is getting the extracted amounts onto the right accounts and tax treatments before the bill posts, so that what arrives in Business Central or Sage is already correct. Finofo posts coded lines into the tax setup you already have.
What if the invoice never prints the word PST clearly?
Some vendors bury provincial tax inside a combined total. For those, the rule is written differently: reconcile the printed total against the calculated tax, and flag the variance for a human split rather than guessing. Finofo's tax reconciliation checks extracted totals against calculated totals per jurisdiction, so a buried PST amount surfaces as a flagged line instead of a silent miscode.
About Finofo
Finofo is the AI native platform built in Calgary for Canadian finance teams. It brings accounts payable, expense management and purchasing onto one engine, on the cards, bank and ERP a business already uses, with line level extraction, Canadian tax handling and approval workflows designed for multi entity, multi province operations. Finofo does the verification. Finance keeps the judgment.
