Overview
Supplier Contract Matching is the process of linking vendor bills in SmartVendor AP Invoices to supplier contracts in your ERP/System of Record (SoR).
When a supplier contract match is found, SmartVendor can:
Validate that the invoice is within an active, open contract
Auto‑populate coding and control fields from the contract (for example, worktags, tax applicability, spend categories)
Support contract‑driven approvals and compliance checks
Supplier contract matching complements PO Matching:
For PO‑driven spend, POs are usually the primary match object.
For contract‑driven spend (with or without POs), supplier contracts can supply the governing values for lines and headers.
SmartVendor tracks supplier contract matching in the document audit history so AP teams can see when and how contract data influenced each invoice.
When Supplier Contract Matching Is Used
Supplier contract matching typically applies in these scenarios:
Your ERP (for example, Workday) is configured with supplier contracts that govern:
Rates, amounts, or not‑to‑exceed values
Tax applicability and tax treatment
Worktags / coding defaults (e.g., cost center, project, spend category)
You’ve included supplier contract fields in your AP Invoices data mapping and SmartVendor Templates.
Invoice documents:
Contain a contract reference (such as contract number, agreement ID), or
Can be linked to a contract via vendor + entity + coding rules.
In these cases, SmartVendor attempts to match the invoice (and sometimes individual lines) to a relevant contract and use contract data as the source of truth for selected fields.
Contract Eligibility and Status
Before SmartVendor uses a supplier contract for matching or overrides, it checks that the contract is eligible. Eligibility is controlled by:
Status mapping between ERP contract statuses and Auditoria’s internal status types (e.g., Open, Draft, Closed).
Customer‑specific mappings, such as:
Example: For Iowa State University, “Amendment in Process” in Workday was remapped from Draft to Open, so invoices can be written to SoR even when the contract is in that status.
Typical eligibility rules:
Contract must be in an accepted “open‑like” status based on the mapping (e.g., Open, Amendment in Process if configured as open).
Contract must belong to the same supplier (and often entity/ledger) as the invoice.
Contract must not be fully consumed, where the ERP enforces spend or quantity caps.
If the contract does not pass these checks, it is not used for automatic overrides and the invoice remains subject to manual review and standard validation.
How Supplier Contract Matching Works
At a high level, matching proceeds in these steps:
Identify potential contracts
From explicit values on the invoice (e.g., extracted Contract Number or Agreement ID).
From vendor + entity combination, according to your data mapping.
From line‑level indicators (e.g., project, spend category) when mapped.
Filter by eligibility
Only contracts in allowed statuses (per your mapping) and matching vendor (and sometimes entity) are considered.
Contracts outside the allowed statuses (e.g., Closed, Canceled, some Draft states) are excluded.
Resolve to a single best contract
If one contract clearly matches, it is selected.
If multiple contracts match equally, human review may be required; SmartVendor will not automatically override fields from an ambiguous contract.
Apply contract‑driven values
For each field configured in SmartVendor Templates or SmartFlow settings as “PO/Contract match” with override:
If a contract is matched, the field is overridden with the contract’s value.
If no contract is matched, normal population methods apply (extraction, defaults, predictive coding, etc.).
All of this is logged in the document‑level audit history as “matched from supplier contracts” (for fields populated from contract).
Fields Commonly Driven by Supplier Contracts
Supplier contracts often drive the same kinds of fields that POs can drive, including:
Worktags / Coding fields (ERP‑specific):
Cost center, project, program, fund, ledger account, spend category, etc.
Tax‑related fields:
Tax applicability
Default tax options (e.g., “Enter Tax Due to Supplier”).
Service period / dates:
Service start/end periods when governed by the contract.
Other contract attributes:
Contract type, terms, or internal references used to drive approval routes.
Which fields are contract‑driven is configured in:
SmartVendor Templates → Field configuration
(Population method “PO/Contract match” and PO/Contract override setting)
Configuring Contract‑Driven Fields (Templates)
SmartVendor Templates provide a self‑service way to specify exactly how contract matching should affect bill fields:
For each field (header or line) you can:
Set Population Method to PO/Contract match
This tells SmartVendor the field can be populated from either a matched PO or a matched supplier contract.
Enable PO/Contract override
When enabled, if a PO or contract is matched, that value will override extracted or manually entered values.
Set Decimal precision for numeric fields (0–8 decimals) where contract values are numeric (rates, amounts, quantities).
Combine with Fuzzy matching or Predictive coding (where supported) when there is no PO/Contract match.
Example configuration:
Header field Default Tax Option:
Population: PO/Contract match
Override: Enabled
Line field Tax Applicability:
Population: PO/Contract match
Override: Enabled
Interaction with PO Matching
Supplier contract matching often works alongside PO matching:
If both PO and contract are relevant:
POs may govern specific orders/lines, while contracts set higher‑level defaults (e.g., tax, coding).
Templates decide which fields are allowed to be overridden by PO, by contract, or both.
Typical patterns:
PO takes precedence for line‑specific transactional data:
Description, quantity, rate, amount, some worktags.
Contracts drive overarching defaults and controls:
Tax applicability, approval‑related tags, high‑level spend categories.
SmartVendor’s internal logic and your template configuration decide which source wins in a conflict. In most deployments:
If a field is configured for PO/Contract override, and both a PO and contract provide a value, a defined precedence (usually PO, then contract) is applied. Where ambiguity would cause risk, values may be surfaced for human review rather than auto‑overridden.
Audit History and Traceability
Supplier contract matching is fully traceable via the Document History panel:
Every field updated due to a contract match is logged as a SmartBot (system) edit with reason such as:
“matched from supplier contracts”
“PO/Contract override applied”
If a user later edits a contract‑driven field:
The user edit is logged, and any cascading system edits are also recorded.
This ensures that AP, auditors, and support teams can see:
Which values came from extraction
Which were matched from POs
Which were matched from Supplier Contracts
Which were changed manually
Human Review and Recovery Scenarios
Human review is required when:
No supplier contract is found for the vendor / entity combination.
Multiple active contracts could apply, and the system cannot uniquely resolve a match.
Contract status is not mapped as Open (for example, remains as Draft), but the business expects it to be valid for invoices.
Contract‑driven values conflict with user expectations or downstream validation (e.g., wrong tax applicability).
In these situations, AP analysts can:
Adjust header and line coding manually.
Change or clear any contract‑driven fields.
Request updates to data mapping or status mapping (via support/OPS tickets) so that future invoices map to the correct contract statuses and fields.
Best Practices
Align contract status mapping early
Confirm which ERP statuses should count as Open in Auditoria (e.g., “Amendment in Process”).
Use Templates to control impact
Apply PO/Contract override only to fields you truly want governed by contracts (e.g., Tax Applicability, key coding fields).
Keep other fields extraction‑based or user‑driven.
Test on a sample of invoices
Validate that the right contracts are matched and that overridden values match your ERP behavior.
Monitor via audit history
Use the document history to see where contract matching is helping and where additional tuning is needed.