← All Modules
Available Now

Carrier Payment

Close the loop from audit to payment. Approved invoices roll into ACH batches, post to your general ledger, and ship EDI 820 remittance so your carriers reconcile their AR — all from a single queue. The second revenue-generating module on the platform.

Carrier payment queue — out-of-tolerance invoices with variance amounts and approve / void actions

How it works

  1. Audit runs first. The parcel / courier audit agent computes an expected charge per invoice. Carrier Payment reads that number.
  2. 3-way match classifies. Invoice total vs. expected charge vs. BOL reference → one of three outcomes: match_ok (within tolerance), match_exception (outside tolerance, fires a Sprint 6 anomaly event), or pending_match (audit hasn't run yet).
  3. You approve. The approval queue shows exceptions first. Approve a payment and it moves to the next building batch; payments:approve is a distinct permission from payments:manage so you can keep the funds-movement authority with finance.
  4. Seal + dispatch. Sealing a batch generates a NACHA-1 ACH file and an EDI 820 remittance advice in the same step. Both land on S3 and surface as presigned download links — 5-minute TTL because the files carry bank routing and account numbers.
  5. GL posts automatically. Each approved payment runs against your configured allocation rules (percentage / weight-prorated / by-location / default). Postings land in an append-only ledger ready for NetSuite / QuickBooks export.

What you get

3-way match engine

Invoice × expected × BOL, with a configurable tolerance (default 2%). Out-of-tolerance fires a Sprint 6 anomaly event tagged audit.invoice_variance_pct — one queue for review, one state machine.

NACHA ACH file generation

Standards-compliant NACHA-1 output (94-char fixed-width, 10-row padded, ABA check-digit validated). Byte-identical golden-file tested so a refactor can't silently break bank parsing.

EDI 820 remittance

X12 820 Payment Remittance alongside every ACH batch. The trace number links to the NACHA so the carrier's AR system matches the deposit to specific invoices without a phone call.

GL allocation

Four allocation methods (percentage, weight-prorated, by-location, default). Rules evaluated in priority order at approval time; first match wins. Postings append-only for SOX-friendly audit.

Banking credential encryption

Routing and account numbers stored under AES-256-GCM envelope encryption — only the last 4 are visible after save. Master key rotates without data migration.

Segregation of duties

payments:view, :approve, :manage are three distinct permissions. AP staff configure bank accounts + GL rules; finance leadership retains approval authority; auditors get read-only access.

Event lifecycle

Every payment walks a simple state machine:

  • pending_match — audit agent hasn't run yet.
  • match_ok / match_exception — ready for review.
  • approved — approver confirmed, GL posted.
  • batched → sent → settled — in the ACH file, on the wire, reconciled.
  • voided — cancelled pre-send.

Prerequisites. Carrier Payment builds on at least one audit module (Parcel Audit, Courier Audit, LTL, Dedicated Fleet) for the expected-charge signal. It's billed separately — see the pricing page for per-seat vs. per-transaction tiers.

Book a demo See pricing