Skip to content
English
Customer portal
Go to Tai Software
  • There are no suggestions because the search field is empty.

Invoicing, Carrier Bill, and Credit Internals

Exact thresholds behind invoice automation, carrier-bill auto-approval, due dates, credit exposure and holds, remit-to, Canadian tax, and the audit trail.

This internal article documents the exact accounting thresholds and mechanics the Tai TMS uses for customer-invoice automation, carrier-bill auto-approval, bill due dates, customer credit exposure and holds, where a bill's remit-to (pay-to) name and address come from, how Canadian tax lines are treated, and how billing automation writes its audit trail — including the defaults, the per-account overrides, the special-cased accounts, and the settings and feature flags that gate this behavior.

Overview

This is the staff-only reference for the numbers behind accounts receivable automation, accounts payable, and credit control. It gives the exact thresholds for customer-invoice auto-validation, the default tolerances for carrier-bill auto-approval and how they are overridden per organization, how the amount comparison and cents-versus-currency handling work, how bill due dates are derived, which accounts are special-cased, the precise credit-exposure formula, how manual and automatic credit holds behave, where a carrier bill's remit-to pay-to name and address are sourced from, how Canadian tax lines are kept out of carrier-side totals, how the shipment-automation audit log is written for auto-approved bills and automated invoices, and the feature flags involved. Use it when a support case turns on "why didn't this invoice auto-create," "why did this bill go to variance," "why is this due date wrong," "why did this customer get held," "why is the pay-to name on this bill different from the carrier," or "why does the balance look stale."

How it works

Customer invoices can be created automatically when a shipment reaches the trigger point on the customer's billing profile and passes the auto-validation checks. Carrier bills arrive from several sources (electronic carrier freight invoice / EDI 210, a bill-processing integration, a document-processing service, an electronic-pay feed, a bulk upload from Approve Bills, or an unmatched-shipment entry). For each one the system compares the billed total against the sum of the shipment's carrier-side (buy) charge lines, decides whether the difference is inside tolerance, and either records the bill or flags a variance. Credit control runs in parallel: the system sums each customer's exposure, compares it to their limit, and — depending on settings — can place a hold that blocks shipments from advancing into billable statuses.

Business rules & limits

Customer invoice automation — triggers and thresholds

  • Setting: each customer billing profile carries an Invoicing Automation Method (Manually Invoice, Auto Invoice at Billing, Auto Invoice at Delivery, Auto Invoice at Committed) plus Allow Zero Margin, POD Required with Invoice, BOL Required with Invoice, and a Preferred Invoicing Method. An automatic invoice is only considered when the trigger that fired matches the profile's method; a non-matching trigger does nothing and writes no note.
  • Triggers: At Billing is evaluated each time a carrier bill is created for the shipment and again when staff approve bills in Approve Bills (where the Create Invoice checkbox passes a force flag). At Delivery is evaluated when the shipment status becomes Delivered or Complete, once for each payer organization on the shipment. At Committed is evaluated when the status moves into the range from Committed up to, but not including, Delivered.
  • Invoiceable lines: charge lines whose invoicing status is Ready or Not Ready; Has Variance lines are included only on a forced invoice. With no legs or no eligible lines nothing happens.
  • At Billing gate (unless forced): every eligible charge line must already have its billing status Created; otherwise the evaluation stops without writing a note.
  • Shipment types that qualify: truckload, LTL, and drayage. All others (international air/ocean and their combined variants, domestic freight, cartage, small package, supplemental insurance provider, other) fail with "shipment type does not support automation."
  • Per-leg checks (each billed leg must pass):
    • Sum of Sell must be greater than zero and sum of Buy must be greater than zero.
    • Margin (Sell minus Buy) must be greater than zero, or greater than or equal to zero when Allow Zero Margin is on.
    • Rated comparisons run only for the linehaul leg and only when the shipment has a rating record; with no rating record they are skipped. When a rating record exists but has no pricing detail for the billing organization the leg fails ("no pricing history details").
    • Margin delta: current margin versus rated margin must differ by no more than $0.50.
    • Tariff: the linehaul tariff must equal the rated tariff (checked when a tariff is present).
    • ZIP codes: first-pickup and last-drop ZIPs must equal the rated origin and destination ZIPs (checked when present).
    • Freight class: the weight-weighted average class (no-class commodities excluded, rounded to two decimals) may differ from the rated average by no more than 11 percent of the rated average, which permits 50 to 55 but not 50 to 60.
    • Weight: total weight may differ from the rated total by no more than 20 lb.
  • Outcome on pass: the invoice is created and flagged as an automated invoice, a public receivable activity is added, and a customer-invoice automation-log entry is written. Outcome on fail (profile method matched): a private shipment note is written with a header ("Invoice was not auto created for this shipment because auto validation failed.") followed by each failing reason; if the payer has no billing profile with the billing organization the note says so. Failures do not set any variance status.
  • Force-create: a forced invoice is created regardless of the checks and includes Has Variance lines. It is delivered through the automated path only when it also passes every check and the profile method matched.
  • Delivery step: sent only when Preferred Invoicing Method is Email or One Invoice Per Email. The recipient is the payer's invoice-address email; if blank and the payer is also the shipment's end customer, the emails of active staff with invoice notification who have org access (or the shipment's customer staff). No recipient produces "does not have an Invoice Email set up." Required POD/BOL must be attached with public access; a missing one produces "Required POD/BOL is not attached" and a private one "attached, but private." Any failure is logged as a private "Invoice not delivered due to…" note and the invoice stays unsent. When the document-retrieval process later attaches a POD or BOL, it re-runs the delivery for that shipment's unprinted invoices.
  • Variance is separate: the variance-only invoicing view lists shipments whose charge lines are flagged Has Variance by the carrier-bill audit, carrier-reported weight changes, or manual Send to Variance. The invoicing screen's Bill On Variance option lets staff invoice those lines.

Carrier-bill auto-approve tolerances

  • Defaults: underpay tolerance is $2, overpay tolerance is $1 (both in dollars). These are the built-in defaults applied when the payer organization has no override set.
  • Per-organization override: each payer organization can carry its own underpay tolerance and overpay tolerance. When set, the organization's values replace the defaults for that organization's bills.
  • The comparison: the difference is the billed total minus the sum of the buy charge lines.
    • If the difference is positive (the carrier billed more than expected — overpay), it is a variance when the absolute difference exceeds the overpay tolerance.
    • If the difference is negative (the carrier billed less — underpay), it is a variance when the absolute difference exceeds the underpay tolerance.
  • Within tolerance: the bill is created, and the small difference is reconciled into the carrier charges — either absorbed into the line-haul charge only (when the bill is flagged to change line-haul only) or applied to fuel first and then the remainder to line-haul.
  • Out of tolerance: every matched charge line is set to a has-variance status, a variance note is logged, and no bill is created. Nothing is paid until staff work the variance.
  • Charge lines considered: only lines whose billing status is Created, Has Variance, Not Ready, or Ready. Canadian tax lines (see below) are No Accounting when tax updates are on, so they are never matched into a bill or counted in the total.
  • Sources and variants: an EDI 210 / unmatched-shipment path (older model that errors with "Unable to approve bill for multiple transit legs" when the invoice spans more than one distinct leg, and a single-leg model) and a per-transit-leg path used by the bill-processing integration and the document-processor flow that supports pickup, linehaul, delivery, insurance, lumper, customs, warehouse, air, ocean, and other charge types. An Approve Bills bulk upload (using the accounting organization's overrides) and the electronic-pay buy-pricing check (using overrides on the shipment's organizations) apply the same $2 / $1 defaults.
  • PRO numbers: the carrier's PRO from the source is stored on the shipment; a mismatch with the shipment's PRO is logged (for Amino and Central Transport the comparison ignores dashes), and for the RLCA carrier code a leading "I" or "D" is stripped.
  • Unmatched or unprepared: a carrier or vendor that matches no charge line, or no linehaul/pickup/delivery charge line in an eligible status, raises an error and a private payable note on the shipment.

Cents versus currency on electronic invoices

  • Electronic carrier freight invoice (EDI 210) amounts are handled in cents unless the amount is flagged as a currency value. When the currency flag is set, the amount is used as-is; otherwise it is divided by 100 to get dollars. The same variance logic serves both cent-based and currency-based sources, so a mis-set currency flag produces a 100x error and a spurious variance. The document-processor flow always supplies currency values.

Bill due date

  • A bill's due date is the bill date plus net terms. Net terms resolve from the carrier's broker-carrier net-terms setting for carrier bills, or from the vendor's payment terms for vendor bills, and default to 30 days when no term is found. In the per-transit-leg path, a due date supplied by the source is used instead of bill date plus net terms.

Special-cased accounts and constants

  • Shipco (a specific hard-coded customer organization, id 38538): on a successful bill creation for that payer organization, the system additionally generates and attaches the carrier bill document automatically. This is a data-coupled special case tied to that account id.
  • Factoring-company rows are skipped when finding the carrier charges. Organizations of the factoring-company type are excluded from the payer/charge-line match during auto-approval; the carrier's charges are still audited, and the factoring company only affects who the bill is payable to (see the vendor guard below).
  • FedEx carrier-master ids are hard-coded in the inbound electronic-invoice matching (FedEx freight restricts the leg match to specific carrier-master ids). Treat these as data-coupled constants, not general logic.
  • Already-billed charges are skipped. If a carrier charge line is already in the created/billed state, it is treated as already billed and not billed again; a note records that the bill was received for payment but already existed.

Remit-to source — where a bill's pay-to name and address come from

  • A carrier bill's remit-to (the pay-to name and address the bill is paid to) is sourced from one of four settings, held on the carrier record as its Remit To Source: Carrier Name, Carrier DBA, Factoring Company (an assigned factoring org), or User Entered (a manually entered remit-payment company name and address).
  • The whole remit-to feature is gated by the LSP carriers factoring-company management feature flag. When the flag is on, the pay-to name and address are resolved from the carrier's Remit To Source setting. When the flag is off, the legacy selection applies: if the carrier has an assigned factoring org, pay to the factoring company; otherwise, if a remit-payment company name or address was entered, use it; otherwise use the carrier's own name. New broker carriers are stored with Carrier Name as the source when the flag is off; with the flag on, integration onboarding (carrier onboarding, the Parade integration, MyCarrierPackets) no longer seeds the user-entered remit-to from the carrier master.
  • Name resolution: Carrier Name uses the carrier master name; Carrier DBA uses the DBA name and falls back to the carrier name when the DBA is blank; Factoring Company uses the factoring organization's name (and a Factoring Company source with no factoring org assigned reverts to the legacy selection); User Entered uses the entered company name and falls back to the carrier name when the company name is blank. A blank entered company name therefore does not block bill approval or sync. Address resolution: Carrier Name and DBA use the carrier master's mailing address, Factoring Company uses the factoring organization's invoice address, User Entered uses the entered remit-payment address.
  • Where it is used:
    • The manual Approve Bills work queue resolves only the pay-to address through the remit-to setting; the carrier name and vendor name shown on each row are the carrier master's own name.
    • When a bill is registered (manual or auto), and when staff change a bill's pay-to on the accounting summary, the resolved remit-to name and address are stored on the bill as a snapshot. Nothing rewrites that snapshot if the carrier's remit-to setting changes later. Changing a bill's pay-to to an organization or a commission recipient stores that vendor's name and address instead.
    • The vendor name and address pushed to the external accounting system read the stored snapshot where present (the stored address is used when it has a street address and ZIP code; the stored name is used as the check-print name), otherwise they resolve from the carrier's remit-to. (The QuickBooks batch-sync engine decouples the check-payee name from the QuickBooks display name using this same source — see the QuickBooks internals article.)
    • With the flag on, editing a carrier master's name or address copies the new name and address into the remit-to details of every broker carrier whose source is Carrier Name.

Bill vendor guard — factoring organization on the shipment

  • A shipment's linehaul organization can name a vendor organization (typically a factoring company). When a bill is registered or auto-approved without an explicit vendor, that organization is adopted as the bill's vendor only if it is the carrier's remit-to source. It is adopted when the vendor, carrier, or payer is unknown, when the remit-to feature is off, when no broker carrier exists for the carrier and payer, or when the broker carrier's assigned factoring org is not that vendor; otherwise it is adopted only when the carrier's remit-to resolves to Factoring Company. When it is not adopted, the bill is made out to the carrier. The same rule applies to manual bill registration when the flag is on.

Canadian tax lines

  • A charge line with a tax type of GST, HST, or PST is a tax line. The rules apply when the multi-currency tax updates setting (feature flag) is on.
  • A tax line's buy is always set equal to its sell, and its billing status is set to No Accounting, so it is never a carrier-payable line. Tax lines are excluded from buy totals, margin, and consolidation roll-ups, and displayed with a zero buy. Commission calculations always ignore tax lines.
  • Carrier-facing documents (carrier confirmations, the bill document, blind documents, and carrier emails) omit tax rows; the customer's invoice still shows tax.
  • Revisions: when a bill or invoice is revised or modified, each detail is matched back to its charge line by charge-line type, exact accessorial, and tax identity, so a tax line only matches a charge line with the same tax type and an ordinary detail never matches a tax line. A new charge line created for a bill adjustment inherits the tax type of the detail's existing line and gets the same accounting rules. With the flag off the legacy match applies (accessorial blank or equal). Modify Invoice Details prompts to recalculate stale Canadian tax before saving.

Charge-line display order

  • With the charge-line display order flag on, invoice and bill detail lists, delete previews, and the lines synced to QuickBooks are ordered Linehaul first, then Fuel, then every other charge type, with ties broken by the stored detail order.

Automation-log / EDI-file write seam (billing audit trail)

  • Every carrier-bill auto-approve attempt, and every automated customer invoice, records a shipment-automation log entry (the audit trail behind the "Approved by EDI" bill filter and the automation history on a shipment). These writes go through a single automation-log write service rather than being written directly to the logging database.
  • Under the EDI-automation double-write setting, each automation-log row (and the EDI files it references) is written to the logging database and mirrored into the primary TMS database. When the companion read-from-TMS setting is also on, readers (for example the "Approved by EDI" bill search) serve the automation history from the TMS copy instead of the logging database. This is the ongoing "serve EDI and automation history from TMS" migration.
  • Consequence for billing support: if a bill was auto-approved or an invoice auto-created while double-write was off, the TMS copy of that automation row does not exist, so a report or search that reads from TMS will not find it even though the logging-database row is present. A missing "Approved by EDI" flag on an older bill can be this mismatch rather than a lost audit trail. Raw EDI 210 content is visible only to IT support administrators.

Customer credit exposure — exact formula

  • Exposure (total balance) for a customer against a billing organization is:
    • the sum of (invoice total minus amount applied) over that customer's invoices that are not fully paid and where amount applied does not already equal the total, plus
    • the sum of the not-yet-invoiced amount on that customer's shipments whose status is in the range ready through delivered.
  • The customer's credit limit comes from their billing profile with that billing organization (the profile's Credit Limit). Over limit means a limit is set, the limit is greater than zero, and the limit is less than the total balance. The unpaid-invoice part is read from the reporting replica and the not-yet-invoiced part from the primary database.
  • Two definitions of "over limit" exist. The credit-hold engine and the Collections Summary / organization banner use the full balance (invoices plus in-flight shipments). The over-credit-limit lists behind the red dollar-sign markers on shipment lists, accounting shipment search, and the organization list compare only the customer's unpaid invoice balance (sum of invoice totals minus applied) to the limit. A customer can therefore be over limit for the hold engine without the marker showing.
  • These figures are cached (accounting data and credit-limit caches have their own short expirations), so a freshly changed balance can read stale for a short window — a "wrong balance" report is often cache timing, not a logic error.

Credit hold — manual, automatic, and what each part blocks

  • There are two linked structures. The Credit Status on the customer's billing profile (Cash, Credit Approved, One Order at a Time, Continual Credit Card, Credit Hold, Collections) is what blocks shipment status moves. A Credit Holds list entry (customer, optional tariff owner, notes, Active) is what blocks rating.
  • Linking rules: saving a customer's billing profile with Credit Status set to Credit Hold adds an active list entry (customer-type organizations only); changing the status away from Credit Hold deletes the customer's all-tariffs entry. Deleting a list entry from the Credit Holds screen removes only that entry and does not change the Credit Status, so shipments stay blocked until the status is changed.
  • Shipment gate: while the customer's Credit Status for the shipment's billing organization is Credit Hold, a shipment transit leg cannot be advanced from below the accountable range into it (accountable starts at Ready). Moves that stay below Ready, canceled legs, and legs already at or beyond Ready are always allowed. The billing organization is matched to the shipment's own accounting organization unconditionally. The gate also applies when a customer books a shipment (the default status is not applied and a private note is written) and when a carrier responds to a confirmation (the carrier is told the shipment is no longer available).
  • Per-shipment exemption: a Bypass Credit Hold action recorded on a shipment lets that shipment cross the gate. The only thing that records it is the automatic hold: the shipment that triggered the hold is exempt. There is no staff-facing control to record one.
  • Rating block: an active list entry with no tariff owner removes every tariff lane for the customer and its organization hierarchy and, if that leaves no rates, rating fails with "No rates are available due to credit status." An entry naming a tariff owner removes only that owner's tariffs. This applies regardless of the computed balance.
  • Automatic hold requires: the billing organization's Auto Apply Credit Hold setting is on and the payer is a customer-type organization. (There is no separate feature flag any more; the former auto-apply flag no longer exists.) The check runs when a shipment is created (except by bulk import, which runs a separate pass over shipments past Committed), changes status, or changes price, and only for shipments below Complete. When the customer is over limit, an active list entry is added, the profile's Credit Status is set to Credit Hold with a "Credit Status" activity note on the customer, the triggering shipment gets the Bypass Credit Hold exemption, and the customer webhook is notified. A shipment created while the customer is over limit also gets a Credit Limit Exceeded alert.
  • There is no automatic release. When the balance later drops under the limit, the open Credit Limit Exceeded shipment alerts are resolved (after a payment is applied), but the hold and the Credit Status stay until staff clear them. Raising the limit does not release a hold either.

Vendor (payables) over-credit-limit check

  • On the Pay Bills and Approve Bills screens, selecting a vendor shows whether the vendor is over its credit limit. The check compares the vendor's outstanding bills minus applied bill payments against the broker-carrier credit limit for the current accounting organization and shows "Available," "Over," or "N/A." It is informational and not an automatic block.

Feature flags and gating (business terms)

  • LSP carriers factoring-company management — gates remit-to resolution (and the vendor guard and the QuickBooks check-payee name); when on, a bill's pay-to name/address come from the carrier's Remit To Source, when off the legacy factoring-else-remit-address selection applies.
  • Multi-currency tax updates — gates the Canadian tax line rules (No Accounting billing status, exclusion from buy totals and margin, tax-aware revision matching).
  • Charge-line display order — Linehaul, then Fuel, then others on invoice/bill lists and QuickBooks lines.
  • Approve Bills dispute-log shipment filter — affects dispute-log filtering in the Approve Bills work queue.
  • EDI-automation double-write and read-from-TMS — the double-write flag mirrors automation-log rows and EDI files into the TMS database in addition to the logging database; the read-from-TMS flag (which only takes effect together with double-write) makes readers serve the automation history from the TMS copy.
  • No longer flags: auto-apply credit hold, the billing-organization match on the credit-hold gate, and shipment stop alerts in Approve Bills (it now always lists unresolved alerts that are not tied to a specific stop) are all unconditional behavior.
  • Balances and over-limit lists are cached, so any of these behaviors can lag briefly behind a just-made change.

Frequently asked questions

Why didn't an invoice auto-create for a shipment whose customer is set to auto-invoice?

In the Tai TMS an automatic invoice requires the trigger to match the customer's Invoicing Automation Method, the shipment type to be truckload, LTL, or drayage, every billed leg to have positive sell and buy and a positive margin (or non-negative with Allow Zero Margin), and, when the shipment has a rating record, the linehaul leg to match the rated margin (within $0.50), tariff, ZIP codes, average freight class (within 11 percent), and weight (within 20 lb). With Auto Invoice at Billing every carrier charge must also be billed. When the method matched but a check failed, a private note on the shipment lists each failed reason; when the trigger did not match the method, nothing is written.

A failed auto-invoice shipment isn't on the variance list. Is that a bug?

No. In the Tai TMS a failed auto-invoice check writes a private note and leaves the shipment in the normal invoicing list; it does not set a variance status. The variance-only view lists shipments whose charge lines are flagged Has Variance by the carrier-bill audit, carrier-reported weight changes, or a manual Send to Variance.

An invoice was created but never emailed. Why?

In the Tai TMS the automated send requires a Preferred Invoicing Method of Email or One Invoice Per Email, a recipient email (the payer's invoice-address email, or invoice-notification staff when the payer is the end customer), and any required POD or BOL attached with public access. Any failure is written as a private "Invoice not delivered due to…" note. When the missing document is later retrieved, the unprinted invoice is sent automatically.

What are the default carrier-bill auto-approve tolerances, and can they be changed?

In the Tai TMS the default tolerances are $2 for underpayment (carrier billed less than expected) and $1 for overpayment (carrier billed more than expected). Each payer organization can override both with its own underpay and overpay tolerance values, which then replace the defaults for that organization's bills, including bills uploaded in bulk from Approve Bills.

Exactly when does a carrier bill go to variance instead of being approved?

In the Tai TMS the system computes the billed total minus the sum of the buy charge lines. If the carrier billed more (a positive difference) it becomes a variance when the absolute difference exceeds the overpay tolerance; if the carrier billed less (a negative difference) it becomes a variance when the absolute difference exceeds the underpay tolerance. Within tolerance, the bill is created and the small difference is reconciled into the charges; out of tolerance, the charge lines are flagged has-variance and no bill is created.

Why did an electronic carrier invoice import at 100 times the right amount?

In the Tai TMS, electronic carrier freight invoice (EDI 210) amounts are treated as cents unless the amount is flagged as a currency value. If that currency flag is set incorrectly for a source, a dollar amount is not divided by 100 (or a cents amount is), producing a 100x error and usually a spurious variance. Check whether the incoming amount was flagged as a currency value.

How is a carrier bill's due date calculated?

In the Tai TMS a bill's due date is the bill date plus net terms. Net terms come from the carrier's broker-carrier net-terms setting for carrier bills, or the vendor's payment terms for vendor bills, and default to 30 days when no term is configured. For bills approved through the per-transit-leg path, a due date supplied by the source wins. A wrong due date usually traces to a missing or unexpected net-terms setting.

What exactly counts toward a customer's credit exposure?

In the Tai TMS, exposure is the sum of the unpaid portion (total minus amount applied) of the customer's not-fully-paid invoices, plus the not-yet-invoiced amount on the customer's shipments in the ready-through-delivered status range, calculated per billing organization. Over-limit means the customer has a limit greater than zero and that limit is less than this total balance. The red dollar-sign markers on shipment and organization lists use only the unpaid invoice balance.

A customer's balance dropped under the limit but they're still on hold — why?

In the Tai TMS, there is no automatic release of an automatic credit hold. When the balance falls back under the limit only the open Credit Limit Exceeded shipment alerts are resolved; the customer's Credit Status stays at Credit Hold and the Credit Holds list entry stays active until staff clear them. Deleting the list entry alone does not release shipments, because the shipment gate reads the Credit Status; change the Credit Status away from Credit Hold.

What has to be true for a customer to be placed on credit hold automatically?

In the Tai TMS, the billing organization must have its Auto Apply Credit Hold setting turned on, the payer must be a customer-type organization, and the customer's full exposure must exceed a limit that is greater than zero. The check runs when one of the customer's shipments below Complete is created, changes status, or changes price. The system then adds an active Credit Holds entry, sets the customer's Credit Status to Credit Hold, and exempts the triggering shipment. If any condition is missing, the hold is not applied automatically.

Why does a customer on credit hold get "No rates are available due to credit status"?

In the Tai TMS an active entry on the Credit Holds screen, with no tariff owner, removes every tariff rate for the customer and its organization hierarchy, and rating reports that message when nothing else remains. An entry that names a tariff owner removes only that owner's tariffs. The block does not depend on the balance.

Can staff exempt one shipment from a credit hold?

Not directly. In the Tai TMS the Bypass Credit Hold exemption is recorded automatically for the shipment that triggers an automatic hold; there is no staff-facing control to record it for another shipment. Staff release the customer's shipments by changing the Credit Status away from Credit Hold.

Which accounts are special-cased in the billing logic?

In the Tai TMS, the Shipco customer organization (id 38538) additionally auto-generates and attaches the carrier bill document on a successful bill creation; factoring-company organizations are skipped when finding the carrier charges for auto-approval; and specific FedEx carrier-master ids are hard-coded for FedEx freight leg matching on inbound electronic invoices. These are data-coupled special cases, not general behavior.

Why is the pay-to name on a carrier bill different from the carrier's own name?

In the Tai TMS, a carrier bill's remit-to pay-to name and address come from the carrier's Remit To Source setting, which can be Carrier Name, Carrier DBA, Factoring Company, or User Entered. When the LSP carriers factoring-company management feature flag is on, that setting decides the pay-to; when it is off, the legacy rule applies (assigned factoring org, else an entered remit-payment address, else the carrier's own name). The resolved name and address are stored on the bill when it is registered and are also what gets pushed to the external accounting system, so a bill can pay to a factoring company or a user-entered name without the carrier record itself changing. A User-Entered source with a blank company name, or a DBA source with no DBA, falls back to the carrier name, so approval does not block. The Approve Bills list still shows the carrier master name.

A carrier's remit-to changed but an older bill still shows the old pay-to. Why?

In the Tai TMS, the resolved pay-to name and address are saved on a bill when it is registered or when staff change its pay-to, and nothing updates that snapshot when the carrier's Remit To Source or details change later. Change the pay-to on the bill (accounting summary) to re-resolve it.

Why was a bill for a factored carrier made out to the carrier instead of the factoring company?

In the Tai TMS, a factoring organization on the shipment's linehaul organization becomes the bill's vendor only when it is the carrier's remit-to source. With the remit-to feature on, if the carrier's Remit To Source is not Factoring Company (or the assigned factoring org is a different organization), the bill is made out to the carrier. Set the carrier's Remit To Source to Factoring Company to pay the factoring company.

How are Canadian tax lines treated on carrier bills and margin?

In the Tai TMS, with the multi-currency tax updates flag on, GST, HST, and PST lines have buy equal to sell and a No Accounting billing status, so they are never matched into a carrier bill, never counted in buy totals, margin, or consolidation roll-ups, and are omitted from carrier-facing documents. The customer invoice still shows tax. Bill and invoice revisions match tax lines only to lines of the same tax type, so an adjustment does not overwrite a tax line.

A bill was auto-approved but doesn't show as "Approved by EDI" — where did the audit trail go?

In the Tai TMS, auto-approved bills and automated invoices write a shipment-automation log entry through a single write service. Under the EDI-automation double-write setting, that entry is mirrored into the TMS database in addition to the logging database, and when read-from-TMS is also on, searches like "Approved by EDI" read the TMS copy. If the bill was auto-approved while double-write was off, the TMS copy was never written, so a TMS-based search will not find it even though the logging-database row still exists. That is a read-source mismatch from the migration, not a lost audit trail.