Enterprise resource planning systems have been processing supplier payments for decades. For domestic payments to established vendors, they do this extremely well. Payment terms, bank routing, tax treatment, approval workflows: all of it is handled within the ERP, producing clean payment records and complete audit trails.
For international payments to new suppliers, the picture is considerably less complete. The gaps are not bugs in the ERP. They reflect design assumptions about what supplier payments look like that were reasonable when these systems were built and are now systematically wrong for a meaningful portion of enterprise payment volume.
The Withholding Calculation Problem
Most ERP systems have some mechanism for recording withholding on foreign supplier payments, but their ability to calculate the correct withholding amount independently is limited. The standard approach is to configure withholding tax codes at the vendor level and rely on the tax team to ensure the correct code has been applied. When the vendor record is wrong or when no one has confirmed which treaty article applies to the specific payment type, the ERP processes the payment with whatever withholding code it finds in the record.
The underlying issue is that U.S. withholding on foreign supplier payments is genuinely complex. The applicable rate depends on the type of income (services, royalties, interest, dividends each carry different default rates), the supplier's country of residence, whether a tax treaty is in effect and which specific article of the treaty applies, the supplier's entity type, and the information provided on their W-8 form. A payment that looks like a service fee might actually be treated as a royalty payment depending on what was delivered. A treaty that reduces the withholding rate on dividends may have no impact on service income from the same country.
ERPs do not analyze income type at the time of payment processing. They apply a pre-configured code. In practice, this means the AP team or tax team must manually determine the correct withholding treatment before payment, update the vendor record, and verify that the correct code has been applied. For teams processing large volumes of international payments with diverse income types, this manual step is a material source of error and rework.
The KYB Verification Gap
Know-Your-Business verification for international suppliers requires confirming legal entity existence in the relevant jurisdiction, cross-referencing beneficial ownership where required, checking the entity against OFAC's Specially Designated Nationals list and other relevant sanctions databases, and in some cases confirming that the payee information matches the entity behind the invoice.
ERP systems do not perform any of this verification. They store the results of verification that was performed externally, but they have no mechanism to initiate or track a KYB check, connect to sanctions screening databases in real time, or flag payments where the compliance review has not been completed.
This means the verification workflow lives entirely outside the ERP, typically in a combination of email, spreadsheets, and whatever compliance tooling the legal or risk team uses. When all of that runs smoothly and the documentation is properly attached to the vendor record, the ERP has a complete compliance record. When it does not run smoothly, or when a new international supplier is added under time pressure without a complete review, the ERP reflects whatever was entered rather than whether the verification was actually done.
Treaty Analysis Requires External Judgment
The U.S. maintains bilateral tax treaties with more than 60 countries. Each treaty has its own rate schedule, its own definition of permanent establishment, and its own limitations-on-benefits provisions that restrict which taxpayers can access treaty benefits. Applying treaty benefits correctly to a specific payment requires reading the right articles of the right treaty and matching them to the income type of the specific payment.
No ERP system performs this analysis. At best, an ERP can store a withholding rate at the vendor or vendor-invoice level after a tax professional has made the treaty determination. For organizations processing diverse international payments, the treaty determination must happen before the rate is entered, and someone must be accountable for keeping that determination current. Treaty rates change when treaties are modified or when new technical explanations and IRS rulings update the interpretation of existing articles.
A practical example: a payment to a software developer in India for services rendered remotely is generally subject to the U.S.-India income tax treaty, which provides reduced withholding rates for certain business profits. But whether the income qualifies as business profits or falls into a different category with a different treaty rate, and whether the supplier's W-8BEN-E reflects the correct treaty article citation, requires analysis that the ERP cannot perform.
Real-Time Sanctions Screening Does Not Exist in Standard ERP Configurations
OFAC sanctions lists are updated on an unpredictable schedule. New designations happen without advance notice. An entity that cleared a sanctions check during onboarding last year may appear on a new list today. OFAC guidance is that sanctions screening should occur at the time of payment, not only at the time of onboarding.
Standard ERP configurations do not perform real-time sanctions screening at payment execution. They may have fields where a sanctions check result can be recorded, but the check itself must be performed externally and the result entered manually. For organizations processing large volumes of payments, ensuring that every international payment has been screened against the current OFAC list at the time of payment processing requires either an integration with a sanctions screening service or a manual process that is error-prone at volume.
The integration path is available to large organizations with the technical resources to build and maintain it. For the majority of enterprise AP teams, the sanctions screening happens as part of vendor onboarding and is not re-run at payment time unless there is a specific trigger to do so.
Where These Gaps Compound Each Other
The withholding, KYB, and sanctions gaps are individually manageable with good process design and appropriate staffing. What makes them particularly problematic for international one-off payments is that they compound: a payment that requires manual withholding analysis, external KYB verification, and sanctions screening against a current list, combined with a W-8 form that needs to be collected from a supplier in another time zone, produces a multi-week coordination effort for what should be a routine payment.
Each gap adds days to the payment timeline. The manual coordination required to close each gap consumes AP staff hours that have no return for a one-time payment. And when something goes wrong, it is typically not caught until the payment is already in the queue, at which point the correction process is more disruptive than it would have been if the gap had been addressed at the start.
The ERP is not going to solve these problems. They reflect structural limitations of systems designed for a different era of supplier relationships. The practical response is to route one-off international payments through a workflow specifically designed to handle these requirements at payment time, rather than patching the ERP's gaps with manual steps that scale poorly and fail silently.
We are not saying ERP systems are inadequate for the work they were designed to do. For repeat domestic and international suppliers with established vendor records, they are the right infrastructure. The argument is narrower: that one-off international payments to new suppliers expose a set of gaps that ERPs were not designed to fill, and that filling those gaps manually is not a scalable or reliable approach for teams with meaningful volume of first-time international payments.