In the Ariba procure-to-pay process, Check Request is a common non-purchase-order payment method. However, many users notice that Ariba's Check Request does not generate an invoice record like the standard invoice process. This design often raises questions—why is this the case? Are the documents supporting the request uploaded as attachments? If there is no invoice number, how can duplicate payments to the same supplier be prevented?

Why does Check Request not generate an invoice?

According to Ariba's system logic, Check Request is mainly used to handle payments that do not go through purchase orders or goods receipt confirmation, such as refunds, reimbursements, one-time fees, or small miscellaneous expenses. Such requests essentially fall into the "direct payment" category, and the system defaults to not triggering the invoice matching process, so no standard invoice number is generated. This design aims to simplify operations and avoid forcibly incorporating non-purchase payments into the three-way matching (purchase order, goods receipt, invoice) control framework.

It should be emphasized that this behavior is not a defect, but rather Ariba's differentiated configuration for different payment scenarios. If an enterprise wishes to mandate invoices, it needs to enable "post-invoice validation" in procurement policies or workflows, or switch to the standard invoice process.

How are supporting documents uploaded?

For Check Requests, users typically need to upload contracts, quotations, approval emails, or other supporting documents as attachments to the Ariba request. When creating a Check Request, the system provides an "Attachment" area where formats such as PDFs, scanned documents, or images can be uploaded. These attachments flow into the approval process along with the request for finance or procurement personnel to review, thereby serving as the basis for payment instead of an invoice.

It is recommended to clearly name files when uploading attachments (e.g., "Supplier Name-Date-Purpose") and reference relevant contract numbers or internal reference numbers in the request remarks for subsequent audit traceability.

How to prevent duplicate payments?

In the absence of an invoice number, preventing duplicate payments requires relying on multiple control measures:

  • Unique Request ID:Each Check Request generates a unique Request ID in Ariba. Finance should use this ID as the primary key during payment and reconcile it with bank payment records.
  • Supplier master data verification:Before creating a request, check the supplier profile for recent payment records with the same amount and purpose.
  • Approval and segregation of duties:Ensure that Check Requests undergo independent approval, and that payment execution and request creation are handled by different personnel.
  • Regular reconciliation:Export Ariba payment lists monthly and perform three-way reconciliation with bank statements and the general ledger to promptly identify abnormal duplicates.

Additionally, some enterprises set up "duplicate payment check" rules outside Ariba (e.g., in ERP systems) to automatically block payments based on combinations of supplier name, amount, and date.

Practical recommendations

If your enterprise frequently uses Check Requests, it is recommended to confirm with the Ariba administrator or implementation consultant whether the "mandatory invoice" option can be enabled in the system configuration. If not feasible, internal financial policies should clearly state that all Check Requests must include sufficient supporting documents and designate a person responsible for monitoring duplicate payments.

Note: This article is compiled based on user questions and does not constitute a complete description of Ariba's official functionality. Specific behavior may vary depending on version, tenant configuration, or enterprise custom settings.