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. Roughly a mid-market shop: wires and EFTs out the door, enough volume 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 (PwC's Canada other-taxes overview is a clear one) 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.
A second problem shows up after the first "AI coded it" win. 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. In demos, finance co-wrote the instruction live: when PST appears, put that balance on the same GL as the product line.
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.
Staging shows the surface we are describing. Vendor profiles carry Extraction rules with whole-document and by-field instructions. Invoice lines support tax breakdowns. We have verified HST ON samples in staging. Other GST/PST/QST variants show up across demos even when a single staging sample does not display every combination. Collaboration comments sit on fields so a reviewer can challenge a coding choice without rebuilding the email thread.
Live extract still needs a human pass. In the same seafood session, results were strong and remaining math or coding fixes were still on the table. Rules are only as clear as the policy the author typed. Ambiguous policy produces ambiguous automation.
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.
Where this does not help
We deliberately did not build a silent GL brain that invents your PST policy from thin air. Without a clear rule, or a careful human correction you then promote into a rule, the system will not magically know that your seafood product PST belongs with inventory while your office-supply PST belongs somewhere else.
We also did not promise zero-touch posting on noisy packs. Fisherman tickets and overloaded PDFs still deserve a review eye for math. Extraction rules reduce rekeying. They do not retire judgment.
We will not claim every provincial tax flavor was proven on one staging screenshot. Demos and product design support line-level Canadian tax handling. Your chart of accounts and provincial edge cases still need a working session with your real invoices.
And we will not confuse "PST on product" with tax advice. How your entity recovers GST/HST, how you treat partially exempt activity, and how provinces define taxable services are questions for your tax advisor. We encode the booking rule you already believe is correct.
FAQs
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, not replacing Business Central or Sage tax setup.
What if the invoice never prints the word PST clearly?
Then the rule cannot fire on a label that is not there. Some vendors bury provincial tax inside a combined total. Those documents need a different instruction or a human split before you pretend the policy is automated.
Close
The accountant did not need another pitch about AI reading invoices. They needed a place to type the sentence their team already uses when training new clerks: when PST shows up, put it on the product account.
That sentence is the product. The PDF can keep changing. The policy should not have to be rediscovered every Friday afternoon when the next odd pack arrives.
