This article describes the end‑to‑end workflow for AR Remittances, from receiving customer remittance files in an email mailbox to creating payment records in your system of record and optionally exporting payment data to a secondary destination.
The steps below assume you have already:
Connected your AR mailbox and Workday tenant in SmartCustomer.
Enabled the AR Remittances SmartFlow skill and selected your processing mode (Collaborative or Autonomous).
[Optional] Configured a secondary destination (SFTP) for CSV exports.
1. Customer sends remittance advice
Your customer sends an email to the configured AR remittances mailbox.
The email typically includes one or more attachments containing payment details, for example:
Bank or customer remittance advice
CSV or Excel exports from the customer’s internal systems
Remittance PDFs (including large, multi‑page documents)
Supported file types for AR Remittances are:
PDF
CSV
XLS
XLSX
Files in unsupported formats are not processed as AR Remittances and may need to be handled outside the product.
2. SmartCustomer ingests email and attachments
SmartCustomer continuously monitors the connected AR mailbox and:
Ingests new emails and metadata (sender, subject, received date).
Scans attachments and attempts to classify them as:
AR Remittance
Other
Each attachment that is classified as an AR Remittance becomes a remittance document in SmartCustomer and appears in the Documents → Active Data view for AR Remittances.
Notes:
A single email can result in multiple remittance documents if there are multiple relevant attachments.
A single remittance file can result in one or more payment records, depending on extraction rules and customer‑specific mapping (for example, large multi‑page files that represent multiple payments for the same customer).
3. Remittance extraction and customer association
Once a document is created, SmartCustomer runs extraction and mapping.
3.1 Header extraction
For each remittance document, SmartCustomer attempts to extract a standard set of header fields, including (where present):
Received Date
Customer Name
File Type
Payment Date
Payment Number
Currency
Total Amount
Entity
Payment Type
Transaction Reference
These fields are visible in the Active Data tab. They form the basis for:
Identifying the customer
Creating the Workday payment header
Driving validation and routing decisions
3.2 Line‑level extraction (remittance advice lines)
Line‑level or “remittance advice” fields (for example, invoice number, PO number, claim number, amount to apply) are:
Not standardized across customers or file formats.
Typically configured on a per‑customer and per‑format basis (for example, different mappings for CSV vs Excel vs one or more PDF layouts).
Maintained as part of a custom mapping owned by implementation and ML teams.
Behavior:
For customers with configured mappings, AR Remittances extracts payment lines and exposes them in the document detail view and as Workday payment line data.
For customers without detailed mappings, only header‑level information may be available, and additional manual work or configuration is required.
AR Remittances does not apply payments to invoices in Workday. Instead, it creates unapplied payment records with the remittance advice data required for downstream automation or batch processes to apply those payments.
3.3 Matching to a customer
As part of extraction, SmartCustomer attempts to associate each remittance document with a customer:
If the customer is found in SoR and synced to SmartCustomer, the document is linked to that Customer record.
If the customer cannot be determined automatically, the document remains in Active Data with missing/ambiguous customer fields and requires manual assignment.
Customer enrollment (for AR Helpdesk and AR Remittances) affects whether records can move through the workflow in Autonomous mode.
4. Review in Active Data (Collaborative and Autonomous)
All new AR Remittances documents first appear in the Documents → Active Data tab. The behavior from this point depends on your Write to SoR mode.
4.1 Collaborative mode
When AR Remittances is configured in Collaborative mode:
All documents stay in Active Data until a user explicitly triggers Write to SoR.
Users can:
Open a document and view:
Original email and attachment
Extracted header fields
Any extracted remittance advice lines
Correct or complete extracted values (for example, Payment Date, Entity, Payment Type).
Mark documents as Not a payment when a file was misclassified.
After review, the user selects Write to SoR (for one or multiple documents) to create Workday payments.
This mode is recommended when:
Extraction and mapping are still being tuned.
You are onboarding the first set of customers to AR Remittances.
The AR team needs full oversight of which payments are created in Workday.
4.2 Autonomous mode
When AR Remittances is configured in Autonomous mode:
For eligible documents (for example, correctly extracted, known customer, valid entity, no failed validations), SmartCustomer can automatically:
Trigger Write to SoR.
Create the Workday payment record in the background.
Documents that fail validations, encounter write errors, or do not meet autonomous criteria remain in Active Data with a status that indicates the error or required action, for example:
Validation error
Write failed
Missing customer or entity
Users can then:
Correct the data and manually re‑trigger Write to SoR, or
Dismiss documents that should not result in payments.
5. Write to SoR (Workday payments)
When Write to SoR is triggered (either manually or autonomously), SmartCustomer:
Validates required fields for payment creation, including:
Customer
Entity (legal entity in Workday)
Currency
Total Amount
Payment Date
Payment Type
Sends a Create Customer Payment request to Workday using the configured connector.
Records the outcome in the document’s status and captures the Workday payment external ID when successful.
Key points:
Payments are created as unapplied in Workday.
Downstream Workday processes (for example, scheduled batches) apply the payment to one or more invoices based on the remittance advice lines.
If Workday rejects the payment (for example, unsupported entity configuration, invalid customer, or currency mismatch), the document in SmartCustomer shows a failed or error status, and no payment record is created.
Once a payment is successfully written to Workday:
The remittance document moves from Active Data to Written to SoR.
The Written to SoR tab shows:
Workday payment external ID
Final status (for example, Record updated)
Key payment details and any indication of secondary‑destination write status.
6. Write to secondary destination (SFTP / CSV) (Optional)
If you have configured an additional destination for AR Remittances:
In the SmartCustomer configuration for AR Remittances, you select:
Write to secondary destination (SFTP).
The write cadence: 24 hours, 12 hours, 4 hours, or 1 hour.
SmartCustomer generates CSV files and sends them to the configured SFTP server on the chosen schedule (or when you manually trigger Sync now, if available).
The CSV export includes:
Standard header fields (customer, entity, payment date, payment number, currency, total amount, payment type).
Mapped line‑level fields, such as:
Invoice or claim identifiers
Amount to pay / applied amount
Any custom fields required by downstream reporting tools.
For deployments that integrate with Workday Prism:
The CSVs are consumed by Prism as a secondary data source for AR reporting and analytics.
Every exported row includes the SoR external ID of the payment, so Prism can cross‑reference the payment data in Workday.
Zero Payment Records (overview only)
For customers that cannot create zero‑amount payments in Workday:
An optional configuration allows documents with Total Amount = 0.00 (and line “Amount to Pay = 0.00”) to be:
Written only to the secondary destination, and
Not created as payments in Workday.
These still appear in Written to SoR with an indication that no Workday payment record was created, but a secondary‑destination record was written.