Accounting API Integration

The TAI Accounting API lets you keep an external accounting system (QuickBooks, Sage Intacct, NetSuite, custom ERP, etc.) in sync with the TMS. All accounting data flows through a consistent pull → process → confirm loop. Payments can travel either direction: pull outstanding records from the TMS or push payments into it.


Prerequisites

RequirementDetails
API KeyGenerated by a user with TMS Site Admin permissions under Public Authentication Keys
Auth headerAuthorization: Bearer <api-key> on every request
Base URLhttps://<your-instance>.taicloud.net

The 8 Core Calls

The integration is built on 8 call types, grouped into five resource areas:

#ResourcePull (GET)Approve / Create (POST)Confirm Sync (PUT)
1Invoices (AR)
2Invoice Payments (AR)
3Bills (AP)
4Bill Payments (AP)
5Commissions

Workflow Overview

TMS                               Your App / Accounting System
 │                                        │
 │── GET /Accounting/v2/{resource} ──────►│  1. Pull unsynced records
 │   ?syncStatus=Unsynced                 │
 │                                        │  2. Create records in your system
 │                                        │     (capture your transactionId)
 │◄── PUT /Accounting/v2/{resource}/Sync ─│  3. Confirm sync back to TMS
 │    { status, transactionId }           │

Accounts Receivable (Invoices)

Pull unsynced invoices

GET /PublicApi/Accounting/v2/Invoices?syncStatus=Unsynced&invoiceStartDate=2024-01-01
Authorization: Bearer <api-key>

Pull all invoices for a specific shipment

GET /PublicApi/Accounting/v2/Invoices/Shipment/{shipmentId}
Authorization: Bearer <api-key>

Pull a single invoice by ID

GET /PublicApi/Accounting/v2/Invoices/{invoiceId}
Authorization: Bearer <api-key>

Approve an invoice (triggers billing)

POST /PublicApi/Accounting/v2/Invoices
Content-Type: application/json

{
  "shipmentId": 12345,
  "invoiceDate": "2024-06-01T00:00:00Z",
  "markAsPrinted": false
}

Send an unapproved invoice to variance

POST /PublicApi/Accounting/v2/Invoices/Variance?shipmentId=12345
Authorization: Bearer <api-key>

Confirm invoice sync (after creating in your system)

PUT /PublicApi/Accounting/v2/Invoices/Sync
Content-Type: application/json

{
  "invoiceId": 987,
  "status": "Synced",
  "transactionId": "QB-TXN-001"
}

Accounts Payable (Bills)

Bills follow a broker-controlled approval workflow. After a carrier is booked on a shipment, the broker applies their own internal rules and validation logic (e.g. amount matching, rate confirmation checks). Once all conditions are satisfied, the broker submits the approval to the TMS via the API — that approval call is what creates the approved bill in the TMS and makes it ready for carrier payment.

Shipment booked with carrier
         │
         ▼
Your system applies broker rules / filters
  - Does the bill amount match the rate con?
  - Are all required documents attached?
  - Does it fall within variance thresholds?
         │
    ┌────┴────┐
  Pass?     Fail?
    │          │
    ▼          ▼
POST /Bills/Approve   POST /Bills/Variance
    │
    ▼
Bill created in TMS → ready for carrier payment

Pull unsynced carrier bills

GET /PublicApi/Accounting/v2/Bills?syncStatus=Unsynced&billStartDate=2024-01-01
Authorization: Bearer <api-key>

Pull bills for a specific shipment

GET /PublicApi/Accounting/v2/Bills/Shipment/{shipmentId}
Authorization: Bearer <api-key>

Pull a single bill by ID

GET /PublicApi/Accounting/v2/Bills/{billId}
Authorization: Bearer <api-key>

Approve a bill (creates it in TMS after broker rules are met)

POST /PublicApi/Accounting/v2/Bills/Approve
Content-Type: application/json

{
  "shipmentId": 12345,
  "vendorId": 111,
  "vendorType": "Carrier",
  "transitLegType": "Main",
  "billDate": "2024-06-10T00:00:00Z",
  "billDueDate": "2024-07-10T00:00:00Z",
  "billNumber": "INV-9876",
  "billAmount": 2200.00
}

Required fields: transitLegType, billNumber, billAmount

Send an unapproved bill to variance (rules not met)

POST /PublicApi/Accounting/v2/Bills/Variance
Content-Type: application/json

{
  "shipmentId": 12345,
  "vendorId": 111,
  "vendorType": "Carrier",
  "transitType": "Main"
}

Confirm bill sync (after recording in your external system)

PUT /PublicApi/Accounting/v2/Bills/Sync
Content-Type: application/json

{
  "billId": 654,
  "status": "Synced",
  "transactionId": "QB-BILL-003"
}

Accounts Payable (Bill Payments)

Use these to push carrier payments from your external system into TMS, or to pull payments already recorded in TMS.

Pull unsynced bill payments

GET /PublicApi/Accounting/v2/BillPayments?syncStatus=Unsynced&asOfDate=2024-01-01

Pull bill payments for a shipment

GET /PublicApi/Accounting/v2/BillPayments/Shipment/{shipmentId}

Push a carrier payment into TMS

POST /PublicApi/Accounting/v2/BillPayments
Content-Type: application/json

{
  "vendorType": "Carrier",
  "vendorId": 111,
  "generalLedgerAccountId": 789,
  "checkDate": "2024-06-20T00:00:00Z",
  "checkRef": "ACH-5001",
  "checkMemo": "Freight payment",
  "checkType": "ACH",
  "lineItems": [
    { "billId": 654, "amountApplied": 2200.00 }
  ]
}

Push an advance payment for a carrier

POST /PublicApi/Accounting/v2/AdvancePayments
Content-Type: application/json

{
  "shipmentId": 12345,
  "amountApplied": 500.00,
  "vendorId": 111,
  "checkDate": "2024-06-18T00:00:00Z",
  "checkRef": "ADV-001",
  "checkType": "ACH"
}

Confirm bill payment sync

PUT /PublicApi/Accounting/v2/BillPayments/Sync
Content-Type: application/json

{
  "billPaymentId": 222,
  "status": "Synced",
  "transactionId": "QB-BPMT-004"
}

Accounts Receivable (Invoice Payments)

Use these when a customer payment is received in your external system and needs to be recorded in the TMS, or when you want to pull payments already recorded in TMS.

Pull unsynced invoice payments

GET /PublicApi/Accounting/v2/InvoicePayments?syncStatus=Unsynced&asOfDate=2024-01-01

Pull invoice payments for a shipment

GET /PublicApi/Accounting/v2/InvoicePayments/Shipment/{shipmentId}

Push a customer payment into TMS

POST /PublicApi/Accounting/v2/InvoicePayments
Content-Type: application/json

{
  "payerOrganizationId": 456,
  "generalLedgerAccountId": 789,
  "checkDate": "2024-06-15T00:00:00Z",
  "checkRef": "CHK-10042",
  "depositReferenceNumber": "DEP-001",
  "paymentType": "Check",
  "lineItems": [
    { "invoiceId": 987, "amountApplied": 1500.00 }
  ]
}

Confirm invoice payment sync

PUT /PublicApi/Accounting/v2/InvoicePayments/Sync
Content-Type: application/json

{
  "invoicePaymentId": 321,
  "status": "Synced",
  "transactionId": "QB-PMT-002"
}

Commissions

Pull unsynced commissions

GET /PublicApi/Accounting/v2/Commissions?syncStatus=Unsynced&commissionStartDate=2024-01-01

Pull commissions for a shipment

GET /PublicApi/Accounting/v2/Commissions/Shipment/{shipmentId}

Approve a commission for billing

POST /PublicApi/Accounting/v2/Commissions
Content-Type: application/json

{
  "shipmentId": 12345,
  "staffId": 99,
  "commissionAmount": 150.00
}

Confirm commission sync

PUT /PublicApi/Accounting/v2/Commissions/Sync
Content-Type: application/json

{
  "billId": 777,
  "status": "Synced",
  "transactionId": "QB-COM-005"
}

Common syncStatus Values

ValueMeaning
UnsyncedRecord exists in TMS but hasn't been confirmed to an external system
SyncedExternal system has confirmed receipt (via the /Sync PUT)

Tips

  • Date filters are optional on all list endpoints — omit them to fetch all records of a given sync status.
  • transactionId in the Sync confirmation should be the ID your external system assigned (e.g., QuickBooks transaction ID). It's stored on the TMS record for reconciliation.
  • Bill approval is broker-driven — your system owns the validation rules. The TMS doesn't auto-approve bills; it waits for your POST /Bills/Approve call. Use POST /Bills/Variance to flag any bill that fails your checks.
  • Payment direction — decide per use case:
    • Pull model: fetch invoices/bills from TMS, create them in your system, confirm sync.
    • Push model: create payments directly in TMS via POST /InvoicePayments or POST /BillPayments.
  • Advance payments (POST /AdvancePayments) are applied at the shipment level before the bill is fully approved — useful for quick-pay or factoring workflows.