AP Payment Records: Tai → Third Party

What this is for

When the broker cuts a check to a carrier or posts an ACH batch through Tai, the bill is marked paid inside Tai — but the broker's accounting system, bank rec, and vendor-facing carrier-payment portal all still think that money is outstanding. This flow pushes every payment posted in Tai into the target system so vendor balances close, cash accounts debit, and no carrier gets paid twice because two systems disagreed.

Payments are batch-only — there is no Bill Payment webhook. Poll cadence is up to your team's rhythm: after every payment run, or on a schedule matching your bank rec cycle.

Delivery — Batch

GET  /PublicApi/Accounting/v2/BillPayments?SyncStatus=None

View in API Reference →

Returns every bill payment posted in Tai that hasn't been synced. Each payment carries the vendor being paid, the bank/GL it came from, the check reference, and the line-item breakdown across bills.

Example response — real shape returned by the API

[
  {
    "billPaymentId": 1687709,
    "payerOrganization": {
      "organizationId": 40750,
      "name": "Acme Brokerage LLC",
      "address": {
        "streetAddress": "111 Broker Way",
        "city": "LONG BEACH",
        "state": "CA",
        "zipCode": "90802",
        "country": "USA"
      },
      "billToAddress": {
        "streetAddress": "111 Broker Way",
        "city": "LONG BEACH",
        "state": "CA",
        "zipCode": "90802",
        "country": "USA"
      },
      "phone": "",
      "referenceNumber": "",
      "modifiedById": 774705,
      "modifiedByName": "Broker Admin",
      "organizationType": "LSP",
      "modifiedDate": "2017-09-27T20:58:13.697+00:00",
      "createdDate": "2017-09-27T20:58:13.697+00:00"
    },
    "vendor": {
      "vendorId": 903421,
      "name": "Estes Express Lines",
      "vendorType": "Carrier",
      "remitToAddress": {
        "streetAddress": "PO Box 25612",
        "streetAddressTwo": "",
        "city": "Richmond",
        "state": "VA",
        "zipCode": "23260",
        "country": "USA"
      },
      "phone": "+18043211000",
      "modifiedDate": "2024-07-25T19:50:03.38"
    },
    "bankAccount": {
      "generalLedgerAccountId": 1710,
      "accountName": "Operating Checking - Chase",
      "accountCode": "Bank",
      "accountType": "Bank",
      "creditAccount": false
    },
    "checkDate": "2026-09-04T00:00:00+00:00",
    "checkRef": "CHK-104882",
    "checkType": "ACH",
    "externalSync": {
      "status": "None"
    },
    "lineItems": [
      {
        "billPaymentLineItemId": 8549031,
        "billId": 18042026,
        "billNumber": "B-2026-091043",
        "shipmentId": 131382699,
        "amountApplied": 1847.50
      },
      {
        "billPaymentLineItemId": 8549032,
        "billId": 18042027,
        "billNumber": "B-2026-091044",
        "shipmentId": 131382700,
        "amountApplied": 982.10
      }
    ],
    "billType": "Freight"
  }
]

Key fields

Field	Type	Notes
`billPaymentId`	int	Tai's primary key for the payment.
`payerOrganization`	object	Your broker's accounting org that cut the check.
`vendor`	object	Who was paid. `vendor.vendorType` = `Carrier` or `Organization`.
`bankAccount`	object	GL account the payment drew from — includes `generalLedgerAccountId`, `accountName`, `accountCode`, `accountType`.
`checkType`	enum	`Cash`, `Check`, `CreditCard`, `ACH`, `Other`, `EFS`, `HaulPay`, `Convoy`.
`checkRef`	string	Check number, ACH reference, or wire ID.
`checkMemo`	string	Optional free-text memo — often used to list the BOL numbers being paid.
`checkDate`	datetime	Payment date.
`billType`	enum	`Freight` or `Commission`.
`externalSync`	object	`{status, date, referenceNumber}`.
`lineItems[]`	array	One entry per bill being paid down — carries `billId`, `billNumber`, `shipmentId`, `amountApplied`.

Integration notes

Field casing: all responses are camelCase.
One payment, many bills: the lineItems array can hold multiple entries — one check paying several bills is common. Aggregate on your side if your target requires it.
checkType semantics: EFS, HaulPay, Convoy represent third-party payment platforms — your target system may need special handling (or a distinct GL account) for each.
Vendor identification — three ways to cross-reference:
- Natural key (for carriers): DOT/MC number is the canonical join for Carrier vendors, looked up via GET /Carriers/Dot/{dotNumber}.
- Mapping table: save Tai's vendor.vendorId alongside your ERP's vendor key on your side.
- referenceNumber on the Vendor's Organization record: for organization-type vendors, set your ERP's key as the referenceNumber on the Organization record in Tai. Round-trips inline. Not available for pure Carrier vendors.
Bank account mapping: bankAccount.generalLedgerAccountId is Tai's GL account ID; accountCode is the human-readable code. Map to your ERP's bank account for cash-side postings.
Cadence: post-payment-run is ideal (kick off the sync at the end of each check batch). Nightly works if your team is not doing intraday bank recs.
Voids and reversals: if a payment is voided in Tai after sync, Tai does not automatically call your target system. Re-fetch previously-synced payments periodically to detect status changes and reverse on the target side.

Close the loop

Every payment pull — success or failure downstream — must be confirmed back to Tai.

PUT  /PublicApi/Accounting/v2/BillPayments/Sync

View in API Reference →

Full details, enum values, and retry semantics: Sync Status Updates.

When something goes wrong

Failed to post downstream (vendor not on file, GL closed, duplicate check number, etc.) — write the error text on the shipment so a Tai user can act on it. See Shipment Activity Logs.