AR Payment Records: Third Party → Tai
Push customer remittances applied in your ERP or lockbox into Tai to close the corresponding open invoices. Supports multi-invoice deposits and factoring-advance flows.
What this is for
Your bank's lockbox feed drops a customer's wire into your GL. A cash-applications team in your ERP posts the deposit to a set of invoices. A factoring platform advances funds against a batch of your invoices and applies them. In all three cases, the money hits your accounting system first and Tai still shows the invoices as open. This flow pushes the payment(s) into Tai so the invoices close, aging is accurate, and no AR clerk emails a customer to ask about money that arrived last Tuesday.
Same shape as AP Payment Records inbound, just for the sell side.
Create Invoice Payment record
POST /PublicApi/Accounting/v2/InvoicePaymentsRequest payload
{
"payerOrganizationId": 660295,
"generalLedgerAccountId": 115,
"checkDate": "2026-09-04T00:00:00Z",
"checkRef": "WIRE-2026090401",
"depositReferenceNumber": "DEP-20260904-A",
"paymentType": "ACH",
"lineItems": [
{ "invoiceId": 14041027, "amountApplied": 2431.75 }
]
}| Field | Required | Notes |
|---|---|---|
payerOrganizationId | Yes | Tai organizationId of the customer sending the payment. |
generalLedgerAccountId | No | Tai's ID for the bank/GL account the deposit goes into. |
checkDate | Yes | The date the payment was received. |
checkRef | No | Check number, wire ID, or lockbox reference. |
depositReferenceNumber | No | Groups multiple payments into a single deposit — use when a bank deposit slip covers several remittances. |
paymentType | Yes | Same enum as Bill Payments — ACH, Check, Cash, CreditCard, EFS, HaulPay, Convoy, Other. |
lineItems[].invoiceId + amountApplied | Yes | One entry per Tai invoiceId being paid down. Amounts should sum to the total payment. |
Response (200) — an empty body on success. The created invoicePaymentId is not returned inline; retrieve it via GET /InvoicePayments?SyncStatus=None (or another status) if you need it for a subsequent sync-status call.
Integration notes
- Field casing: requests are case-insensitive on parse but responses are camelCase.
- Lockbox-style batches: when your bank feed delivers one wire that pays 12 invoices, send one
POSTwith 12lineItems. Don't split it into 12 calls — Tai models this as one payment with 12 applications, and splitting fragments your reporting. - Partial payments:
amountApplieddoesn't have to equal the invoice's remaining balance. Tai will reduce the invoice's outstanding by that amount and keep the invoice open for the remainder. - Grouping deposits with
depositReferenceNumber: payments sharing this value show up together in Tai's bank-reconciliation reports — useful when one bank deposit slip covers several customer remittances. - Payer identification:
payerOrganizationIdmust be Tai'sorganizationIdfor that customer. If your ERP uses different keys, either maintain a mapping table or set your ERP's key as the customer'sreferenceNumberin Tai and look up viaGET /CustomersByReferencebefore creating the payment. - Factoring advances: if a factoring platform is advancing against invoices before the customer pays, the pattern is the same — the factor is the
payerOrganizationfor that payment, and the settlement (when the customer later pays the factor) doesn't touch Tai.
When something goes wrong
Customer not on file, invoice already fully paid, deposit account missing — post the error on the shipment via Shipment Activity Logs so a Tai user can reconcile it.
Close the loop
PUT /PublicApi/Accounting/v2/InvoicePayments/SyncFull details: Sync Status Updates.
Updated 23 days ago