Inbound Accounting
Records flowing from your accounting system into Tai. Create and update endpoints for bills, invoices, payments, customer masters, and carrier masters — plus the shared sync-status and activity-log mechanics.
The other direction. When something happens in your accounting system that Tai doesn't already know about — a carrier invoice you approved through your AP department, a customer invoice you generated from your ERP's billing engine, a check batch you cut from your bank portal — you push that record back into Tai so Tai's shipment view, aging reports, and operator dashboards stay accurate.
Why this direction exists
Not every accounting event originates inside Tai. Common cases where the target system is the source of truth:
- Vendor invoices come through your AP inbox. A carrier mails a paper invoice; your AP clerk opens the envelope, keys it in their ERP, and matches it against a Tai shipment. Tai needs to know so the pending bill can be closed and the operator sees "Paid" instead of "Pending Approval."
- Customer invoices are generated by your ERP. Some brokerages run their customer billing off a purpose-built invoicing engine, not out of Tai. When that engine emits an invoice, you push it back into Tai so the shipment's financial cycle closes and Tai reports match.
- Checks are cut from your bank portal. Your AP team runs a payment batch through Chase's or Bank of America's portal; the payments hit your GL first, then flow into Tai so vendor balances agree.
- Customer remittances land in your lockbox. Your bank's lockbox feed applies payments in your GL; you then push them into Tai so invoice statuses close.
In each case, the middleware calls Tai's POST create endpoint with the record, gets back a Tai ID, cross-references it, and moves on.
What's in this section
AR side (money in)
- AR Records: Third Party → Tai — create invoices in Tai, post variances, correct sell-side pricing.
- AR Payment Records: Third Party → Tai — apply customer payments to Tai invoices.
AP side (money out)
- AP Records: Third Party → Tai — approve bills, post variances, correct buy-side pricing.
- AP Payment Records: Third Party → Tai — record bill payments cut outside Tai.
Master data (create and update)
- Customer Records: Third Party → Tai — push new customers or update existing ones from your CRM/ERP.
- Carrier / Vendor Records: Third Party → Tai — push carriers, contacts, insurance, and trailer types from your onboarding tool.
Shared mechanics
- Sync Status Updates — the mechanism for cross-referencing every accounting record you create (or approve) in Tai back to your target system's ID. Master-data flows (customers, carriers) do not use this.
- Shipment Activity Logs — the escape hatch for when an accounting record can't be created and a Tai user needs to step in. Master-data flows do not have this fallback.
An important guardrail — Accounting Lock
Two of the inbound endpoints (PUT ShipmentCharges and PUT CarrierCharges) let you correct pricing on a shipment. Both are rejected once a Bill or Invoice has been created against that leg — the charges become immutable at that point. When you hit an accounting-locked leg, the right move is to post a variance instead so a Tai user can reconcile from the UI. Each affected doc has a callout with the specifics.
Updated 23 days ago