BeyondERP.Subscribe

TC-AP-INVMATCH-01 · Test case

Matching validation test pack

A verification activity, kept apart from the configuration steps it exercises so that the step count stays a real number.

Partly verified

Test pack

Preconditions
  1. Use an authorized non-production legal entity, application version and test date. Record the configuration before testing and obtain approval before changing company-wide matching parameters or creating transactions.
  2. Confirm the invoice matching configuration key, vendor and purchase-order number sequences, and the tester's effective security roles.
  3. For the three-way scenarios, enable invoice matching validation; use three-way matching as the effective policy, a documented unit-price tolerance, and Require approval for posting with discrepancies. Use isolated demo purchase orders, product receipts and invoices; restore any changed parameters afterward.
  4. If testing price-total or charges matching, explicitly enable those controls and record their tolerances. A displayed zero in a disabled control is not an active tolerance.
Unverified
Steps
  1. Record the legal entity, application build, actual Accounts payable parameter values, matching-policy overrides, price and charges tolerances, and the roles/duties used for this run.
  2. Positive three-way case: confirm a demo purchase order, post a product receipt for the ordered quantity, enter a vendor invoice at an allowed price, match the receipt, and inspect Matching details before posting.
  3. Negative receipt case: on a separate demo invoice under effective three-way matching, leave the receipt unmatched or invoice more than the matched receipt quantity; inspect Matching details and the posting decision without overriding approval.
  4. Negative price case: on a separate demo invoice, exceed the applicable unit-price tolerance; inspect the unit-price match status and posting decision. If price-total matching is explicitly enabled, also exceed its recorded amount or percentage tolerance and inspect that distinct status.
  5. Override case: where an authorized item, vendor or purchase-order-line override exists, compare the legal-entity default with the effective policy shown for the invoice line and repeat the relevant match check.
  6. Record observed statuses, whether posting was allowed or required approval, and any mismatch between expected and actual behavior. Do not post a deliberately discrepant invoice merely to prove a warning.
Unverified
Expected resultThe matched three-way invoice shows passing quantity and price statuses. The effective policy and applied tolerances agree with the recorded configuration. Normal posting is available only when the configured validation and approval rules permit it.Unverified
Negative caseA missing or insufficient matched receipt fails the three-way quantity check; a price above the applicable tolerance fails the price check. With Require approval configured, posting with a discrepancy needs explicit approval. With Allow with warning, a warning may be displayed while posting remains possible if there are no other errors; record this as the configured behavior rather than calling it a blocked posting.Unverified
Catalog idNot recordedUnverified
Verified on versionNot recorded
Verified on dateNot recorded

Configuration it exercises

AP-INVMATCH-010
Confirm procurement and AP number sequences existNumber sequence · Accounts payable > Setup > Accounts payable parameters > Number sequencesProcess: Perform invoice matching in Dynamics 365 Finance
Partly verifiedAP-INVMATCH-030
Enable invoice matching validationParameter · Accounts payable > Setup > Accounts payable parametersProcess: Perform invoice matching in Dynamics 365 Finance
Partly verifiedAP-INVMATCH-040
Set the default line matching policyParameter · Accounts payable > Setup > Accounts payable parametersProcess: Perform invoice matching in Dynamics 365 Finance
Partly verifiedAP-INVMATCH-050
Decide whether matching policy override is allowedParameter · Accounts payable > Setup > Accounts payable parametersProcess: Perform invoice matching in Dynamics 365 Finance
Partly verifiedAP-INVMATCH-060
Configure price total matching and toleranceParameter · Accounts payable > Setup > Accounts payable parametersProcess: Perform invoice matching in Dynamics 365 Finance
Partly verifiedAP-INVMATCH-070
Define price tolerances by item, vendor or combinationMaster data · Accounts payable > Invoice matching setup > Price tolerancesProcess: Perform invoice matching in Dynamics 365 Finance
Partly verifiedAP-INVMATCH-080
Define charges tolerancesMaster data · Accounts payable > Invoice matching setup > Charges tolerancesProcess: Perform invoice matching in Dynamics 365 Finance
Partly verifiedAP-INVMATCH-090
Set the posting rule for invoices with discrepanciesPolicyProcess: Perform invoice matching in Dynamics 365 Finance
Partly verifiedAP-INVMATCH-100
Assign matching-related duties to AP rolesSecurityProcess: Perform invoice matching in Dynamics 365 Finance
Partly verified

Verification

Verified byTest design derived from Microsoft Learn and the July 2026 business process catalog; positive and negative pre-posting matching checked in USMF on 2026-09-26; separate matched-invoice posting checked on 2026-09-27
EnvironmentUSMF demo sandbox
NotePartial live execution: a received demo PO had effective Three-way matching on both lines despite the company NoMatch default. In an unposted invoice form, baseline price and quantity matches passed; a unit price above the applied 5% tolerance failed price matching; quantity 13 against matched receipts 12 failed quantity matching. Both edited fields were restored and final match status passed; that discrepant draft was not posted. Separately, on 2026-09-27 a clean matched USMF demo invoice totaling USD 209.00 posted successfully, F&O displayed posting complete, and its PO changed to Invoiced. Discrepant posting, warnings, Require approval behavior, and independent persistence of the earlier draft were not tested. Price-total matching remains None and the company posting discrepancy rule is AllowWithWarning. Former step 020 is outside this invoice-matching slice by owner scope decision on 2026-09-27. The catalog's eight level-6 cases are provisionally referenced, not mirrored into separate Atlas records; the owner decision on mirroring remains open, and catalog_id is null because this pack spans multiple cases. See docs/T136-USMF-invoice-tests-2026-09-26.md and docs/T136-USMF-verification-runbook.md.
Still to checkPreconditions, Steps, Expected_result, Negative_case, Catalog_id

← Atlas Hub