Most finance teams have never asked their AP vendor this directly. It is worth asking before a customer or auditor asks you.
Where your AP data lives used to be an IT detail. Now it shows up in customer contracts, vendor risk reviews, and renewal negotiations.
A few cents of difference on one invoice is nothing. The same few cents across thousands of invoices is a recurring line item on every close checklist.
Most AP tools were built around one tax rate per invoice. Canadian invoices routinely need several.
When a foreign vendor does not charge Canadian tax, the obligation does not disappear. It moves to the buyer, and most AP workflows never flag it.
Canada does not have one sales tax system. It has several, layered by province, and a single vendor relationship can touch all of them.
Every tax correction made after posting is a cleanup task. Every one caught before posting is a non event. The difference is entirely about timing.
For a specific set of contracts, US hosted AP data is not just a documentation gap. It is a blocker that shows up at the RFP stage.
You do not need to be a privacy lawyer to understand what Canadian privacy law expects of your finance data. You do need to know where your AP data actually fits.
A currency toggle and a tax field are not the same thing as software designed around how Canadian finance teams actually work.
Blankets that never get formally closed accumulate quietly. The aged blanket portfolio is one of the most common procurement audit findings. Here is the cleanup approach.
Governance is the difference between a blanket PO that operates as designed and one that quietly becomes a control gap. Three roles, clearly defined, fix most of it.
Services blankets work differently from goods blankets. Time, scope, and rates need separate controls. Here is what the service blanket structure should actually look like.
Indirect spend and MRO are the strongest use cases for blanket POs. High volume, low value, predictable patterns. Here is how to set them up so they actually work.
Blankets expire on a defined date or at a defined limit. Either way, the team relying on the blanket needs to know in advance, not on the day operations stall.
Standard three way matching assumes one PO, one receipt, one invoice. Blankets break that assumption in ways that produce systematic matching errors.
The blanket creates the authorization. The releases are where the actual spending happens. Most workflow problems sit at the release level, not the blanket level.
A blanket PO is only as useful as its limit is accurate. Most limits get set by guess and never reviewed. Here is the analytical approach that works.
