What a successful response actually means

A successful Submit_Ad_hoc_Payment call means Workday saved an ad hoc payment document and, if you asked it to, submitted it to the Ad Hoc Payment Event business process. It does not mean a payment was made. Money moves only after the ad hoc payment is approved and then settled. When an orchestration gets a clean response and nobody can find the payment, the document is almost always sitting at one of three stops: saved but never submitted, submitted but waiting in the business process, or approved but not yet settled.

The Administrator Guide describes the web service in exactly these terms: it adds or updates an ad hoc payment, then submits the event through the Ad Hoc Payment Event business process for review and approval. A later step in Workday's own ad hoc payment process is "Settle the approved ad hoc payments."

Stop 1: the request never asked Workday to submit

Ad_hoc_Payment_Data has an optional boolean element named Submit, which the schema labels Save and Submit. That label is the switch between saving the ad hoc payment and sending it into its business process, and the call returns an Ad_hoc_Payment_Reference either way, so the orchestration looks as if it worked. Send Submit as true explicitly rather than relying on a default.

The element order matters. The schema orders the request as Ad_hoc_Payment_Reference, then Business_Process_Parameters, then Ad_hoc_Payment_Data. Inside the data, Ad_hoc_Payment_ID comes first, then Submit, then the payment header and lines. A trimmed request body, written in the Body tab's Create Text Template option of a Send Workday API Request step, looks like this:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
                  xmlns:wd="urn:com.workday/bsvc">
  <soapenv:Body>
    <wd:Submit_Ad_hoc_Payment_Request wd:version="v45.1">
      <wd:Business_Process_Parameters>
        <wd:Auto_Complete>false</wd:Auto_Complete>
      </wd:Business_Process_Parameters>
      <wd:Ad_hoc_Payment_Data>
        <wd:Ad_hoc_Payment_ID>AHP-EQUIP-000123</wd:Ad_hoc_Payment_ID>
        <wd:Submit>true</wd:Submit>
        <wd:Company_Reference>
          <wd:ID wd:type="Company_Reference_ID">COMPANY_01</wd:ID>
        </wd:Company_Reference>
        <wd:Bank_Account_Reference>
          <wd:ID wd:type="Bank_Account_ID">OPERATING_ACCOUNT</wd:ID>
        </wd:Bank_Account_Reference>
        <wd:Payee_Reference>
          <wd:ID wd:type="Supplier_ID">S-000042</wd:ID>
        </wd:Payee_Reference>
        <wd:Currency_Reference>
          <wd:ID wd:type="Currency_ID">USD</wd:ID>
        </wd:Currency_Reference>
        <wd:Payment_Date>2026-11-13</wd:Payment_Date>
        <wd:Payment_Type_Reference>
          <wd:ID wd:type="Payment_Type_ID">ACH</wd:ID>
        </wd:Payment_Type_Reference>
        <wd:Invoice_Line_Replacement_Data>
          <wd:Spend_Category_Reference>
            <wd:ID wd:type="Spend_Category_ID">Equipment_Rental</wd:ID>
          </wd:Spend_Category_Reference>
          <wd:Extended_Amount>1250.00</wd:Extended_Amount>
        </wd:Invoice_Line_Replacement_Data>
      </wd:Ad_hoc_Payment_Data>
    </wd:Submit_Ad_hoc_Payment_Request>
  </soapenv:Body>
</soapenv:Envelope>

The IDs are placeholders; use the reference ID types your tenant has. The schema accepts Supplier_ID, Employee_ID, Ad_hoc_Payee_ID and many other payee ID types. Send it with method POST to the Cash Management service path. Workday's sample orchestrations call SOAP with relative paths such as /soap/v39.0/Resource_Management, so the equivalent here is /soap/v45.1/Cash_Management (or whichever version you build against).

Stop 2: the business process is waiting for someone

With Submit set to true, Workday starts the Ad Hoc Payment Event business process. Whatever approvals, reviews and to-dos the tenant configured on that business process now apply, exactly as they would for a person using the Create Ad Hoc Payment task. The orchestration has finished; the payment is in someone's inbox.

Business_Process_Parameters has an Auto_Complete element. The Cash Management schema says that when it is true, all approvals are approved automatically, all reviews and to-dos are bypassed, and all notifications are suppressed. That makes the payment reach approved status within the call. It also removes every control Finance put on that business process, for every payment the orchestration sends. Treat it as a decision for the process owner, not as a fix to make the integration look complete. A safer pattern is to leave Auto_Complete false and have the orchestration report the reference it created, so approvers know what to expect.

Who may initiate and act on the Ad Hoc Payment Event is set by its business process security policy, separate from the ad hoc payment domains below. The two layers are explained in domain vs business process security policies.

Stop 3: approved is not paid

An approved ad hoc payment still has to be settled before anything goes to the bank. Workday's manual settlement run task, Create Settlement Run, settles "unpaid open items and pending payments". You can also settle a single item from its related actions, which creates a draft settlement run. The account doing this needs Process: Settlement or Process: Ad Hoc Payment Settlement in the Banking and Settlement functional area.

Payment_Date does not cause settlement either. Workday describes it as the date the financial institution processes the payment, and gives the example of entering Friday as the payment date and starting the settlement run on Wednesday. Check the tenant's settlement schedule and run filters before concluding the payment is missing: a scheduled settlement run only auto-selects items that meet its filters for organization, currency and run date, so the ad hoc payment may simply be waiting for a run that selects it.

Read the response for warnings and faults

Two things in the SOAP response decide whether the call really succeeded.

  • Faults. Workday returns errors in a SOAP-ENV:Fault element with a faultcode and a faultstring. The operation declares Validation_Fault, Processing_Fault and Authentication_Fault. Validation failures for this operation include messages such as "Please enter at least one invoice line." and "The total extended amount of all lines must be greater than zero." Have the orchestration test for a fault in the body; do not rely on the step finishing.
  • Exceptions on a successful response. Submit_Ad_hoc_Payment_Response carries the Ad_hoc_Payment_Reference and optional Exceptions_Response_Data. Each Exceptions_Data entry has a Classification (Error or Warning) and a Message. Log any exception data with the reference so a warning is not lost in a "success".

Retries can create duplicates or hit a locked document

The operation adds or updates. Workday's schema documents these behaviours that matter for an orchestration that retries:

  • If you send no Ad_hoc_Payment_ID, each retry can create another ad hoc payment. Supply a deterministic ID built from the source record so a retry addresses the same document.
  • With the request's Add_Only attribute set, a resend fails with "The Web Service is set to Add Only; documents cannot be resubmitted."
  • A payment that is settled or being settled cannot be updated: "The Ad hoc Payment cannot be updated because it has been settled or is in the process of being settled."
  • A canceled one cannot be resubmitted: "The Ad hoc Payment is canceled and cannot be resubmitted."

Before resending after a timeout, read the destination first. Get_Ad_hoc_Payments accepts the company, bank account, payee, currency and a payment date range as criteria.

Security and setup that block the call outright

These fail loudly rather than silently, but they are the next thing to check after the three stops. The Administrator Guide requires the bank account to be configured for ad hoc payments, and the Ad Hoc Payment Event business process and its security policy to be configured. The account needs the ad hoc payment domains in Banking and Settlement: Process: Ad Hoc Payment (NEW), Process: Ad Hoc Payment – CORE and Process: Ad Hoc Payment – View. Paying employees as payees through the web service also needs Process: Ad Hoc Payment – Access Worker.

If the tenant restricts bank accounts or spend categories with segmented security, the account can only use the ones in its segment. Electronic payment types need a settlement bank account on the payee. The schema's message for that is "The Payee entered does not have a settlement bank account or a settlement bank account that matches the payment type defined to process this Ad hoc Payment."

The credential on the step decides which account all of this applies to. If it is an integration system user, its security group needs these grants; see setting up an ISU and its API client.

How to prove a payment was created and paid

Take the Ad_hoc_Payment_Reference from the response and follow it through all three stops in the tenant:

  1. Run Find Payments, filtered to the Ad Hoc Payment payment category. Workday's report filters by company, payee, status and transaction date. Confirm the document exists and read its status.
  2. Open the business process for that ad hoc payment and confirm the Ad Hoc Payment Event is complete, or see whose inbox it is in.
  3. Confirm a settlement run that includes it has been processed. Only then has a payment gone to the bank.

For error patterns that apply to any orchestration, such as a run marked Success with failed steps, see Workday Orchestrate errors and what they mean.

Sources checked