Billing

Set up invoice details and per-customer terms

Two screens control what a Conterminal invoice says and when it comes due. Billing Settings holds your carrier identity, remittance details, and organization-wide defaults. Customer Billing holds one row per customer that can override the terms and record how that party should be billed. This walks both, then shows exactly which value ends up on the invoice.

8 minute setup · Updated July 27, 2026

Both screens are carrier-only.

Billing Settings and Customer Billing load only when your active workspace organization is a carrier (trucker) organization and you hold the tenant_admin or tenant_manager role in it. Anything else redirects to Access Denied. On the Billing home the two cards sit under Billing Management, but they are only made clickable for tenant_admin — a tenant manager sees them greyed out with Tenant admin role required. even though the pages themselves will let that manager in. If you are a manager and the card is dead, open /protected/billing/settings directly.

Company details on the invoice

Open Billing Settings from the Billing Management card labeled “Configure invoice defaults, branding, and payment details.” The page is one long form with three cards and a single Save Billing Settings button at the bottom. Nothing saves until you press it, and it saves all three cards at once.

The first card is Company Details — “Company identity and contact information shown on generated invoices.” Two fields are required.

Company Name (required): Printed as the letterhead on every generated invoice PDF. Leave it blank and the save is rejected with “Company name is required.” If no settings row exists at all, the PDF falls back to the words “Carrier Workspace.”
Carrier SCAC (required): Two to ten letters and digits, no spaces. The field caps at 10 characters, uppercases as you type, and shows PGTN as a placeholder. Its helper text reads “Required for carrier identity, EIR attribution, and terminal SCAC fallback.”
Address, City, State, ZIP, Phone: Printed under the company name as up to three lines: the street address, then city/state/ZIP, then “Tel: <phone>”. Blank fields are dropped rather than printed empty.
Email: Used twice on the PDF — “For ACH/wire transfers, contact <email>” in the payment block and “Questions? Contact <email>” in the footer. When it is blank both lines read billing@conterminal.com.
Logo URL: A URL, not an upload. The image is placed above the company name in the PDF header. There is no preview on this page, so check a generated invoice after you set it.

An empty address prints a placeholder, not nothing.

If Address, City, State, ZIP, and Phone are all blank, the invoice PDF does not simply omit the block — it prints a hardcoded sample address: 123 Terminal Road, Newark, NJ 07114, Tel: (973) 555-1234. That address will go out to your customer. Fill in at least one of those five fields before you send an invoice.

The SCAC is not stored with the rest of the form

Every other field on this page is stored against your organization's invoice configuration. The SCAC is written to your organization's identifier records instead, which is why it can already be filled in on a workspace that has never saved billing settings. Saving replaces those records: Conterminal deletes the organization's existing SCAC identifier rows and inserts a single new one. If exactly one row already carries the value you submitted, it is left alone.

Changing an existing SCAC to a different value clears its primary flag. The replacement row is marked primary only when a primary row already carried the same SCAC you are saving — so a genuine SCAC change leaves your organization with a SCAC identifier that is not marked primary. Nothing on this page shows that flag. If a downstream screen stops recognizing your carrier code after a SCAC change, say so when you contact support rather than re-saving the form.

Invoice prefix, terms, and default FSC

The second card is Billing Defaults — “Applied when customer-specific billing overrides are unavailable.” Three fields.

Invoice Prefix. Required, up to 20 characters, defaults to INV. It is uppercased when saved, and clearing it entirely puts INV back. The prefix is a display decoration on the PDF only: the invoice number stored on the record never changes, and the PDF renders PREFIX-number unless the stored number already begins with that prefix — the check is case-insensitive and accepts either a hyphen or a space. Changing the prefix therefore restyles every past invoice the next time its PDF is rendered; it does not renumber anything.
Default Payment Terms (Days). A whole number from 0 to 365, defaulting to 30. This is the fallback used to compute an invoice's due date when the billed party has no config of its own.
Default FSC %. 0 to 100, in steps of 0.01, defaulting to 0. Read the warning below before you rely on it.

Out-of-range numbers are silently corrected, not rejected.

The two number fields on this card are clamped rather than validated. A payment-terms entry above 365 saves as 365, below 0 saves as 0, and anything unparseable saves as 30. An FSC entry is clamped to 0–100 and rounded to two decimals, and anything unparseable saves as 0. You get the same green Billing settings saved. banner either way, so re-read the fields after saving instead of trusting the banner.

Default FSC % does not price anything today.

Neither this field nor the per-customer FSC % is read when a charge is written or when an invoice is totalled. Each charge carries its own FSC percentage and its own fuel-surcharge amount, fixed at the moment the charge is created; an invoice's fuel-surcharge total is the sum of those stored per-charge amounts. Accessorial charges take their percentage from the accessorial rate card, not from either FSC setting. Treat both FSC fields as a recorded rate you still have to apply when the charge is raised.

Bank remittance details

The third card is Banking & Footer — “Banking details and optional footer text printed on invoices.” It holds Bank Name, Bank Routing, and Bank Account. All three are free text and all three are optional.

What you enter is printed verbatim in the Payment Information block of the invoice PDF. When at least one of the three is filled, the block reads “Please remit payment via ACH/wire:” followed by only the lines you supplied — Bank: …, Routing: …, Account: …. When all three are empty, the block falls back to “Please make checks payable to your company name” and “For ACH/wire transfers, contact your email” instead.

Treat this page as sensitive — it holds bank routing and account numbers.

These fields are the real routing and account numbers that get printed on outgoing invoices. There is no masking on this form: the values are shown in full to anyone who can open the page, which is any carrier tenant admin or tenant manager in your workspace. Review who holds those roles before you fill this card in, do not screenshot the page into a ticket or chat, and never paste these numbers into a support email. If you would rather not print account details at all, leave all three blank — the check-payable fallback is a supported outcome, not an error.

Partial entry is allowed and produces a partial block. A routing number with no account number prints one Routing: line and nothing else, which is rarely what you want. Fill all three or none.

Footer text

Invoice Footer Text is the multi-line box at the bottom of the Banking & Footer card. It replaces the default closing line on the invoice PDF, which is “Thank you for your business!”. The “Questions? Contact …” line underneath it is always printed and is not editable here — it uses the Email field from Company Details.

Keep it short. It renders as a single footer paragraph on a US Letter page with no pagination handling of its own, so a long payment policy is the wrong thing to put here. Leading and trailing whitespace is trimmed, and a box containing only spaces is treated as empty.

Under the footer box, the card shows either Last updated: with a timestamp or No settings saved yet for this organization. That second line is the honest signal that every value on the page is still a form default and nothing has ever been written.

Per-customer overrides

Customer Billing — reached from the card “Manage customer-level terms, FSC overrides, and notes” — opens Customer Billing Configuration, headed “Manage FSC, payment terms, and notes for customers under your organization.” It has two sections: Add Customer Config and Existing Customer Configs.

Adding a config

Pick the customer. The Customer dropdown lists active organizations that are not carrier organizations and do not already have a config with you. Each option shows the company name, plus (#number) when that company has a customer number. If every eligible company is already configured you get “No available customer organizations without a billing config.” and no form at all.
Set FSC % and Terms (days). FSC % accepts 0 to 100 in hundredths and starts at 0. Terms accepts a whole number from 0 to 365 and starts at 30. Both are required. Unlike the Billing Settings form, these are validated rather than clamped — an out-of-range or fractional value is rejected with “One or more required values are invalid.”
Add Notes if useful. A single line, up to 500 characters, placeholder “Optional billing notes.” It is internal — it is not printed on the invoice.
Set the two bill-to policies. Freight Customer and Accessorial Customer each offer Always, Sometimes, and Never, defaulting to Sometimes. These do not affect pricing; they decide whether this party is offered as the bill-to when a delivery order is confirmed.
Select Create Config. Success shows Customer billing settings saved. and the row appears below.

Editing an existing row

Existing rows are listed newest-updated first, each as its own small form with its own Save button. The header shows the company name, Cust# with the customer number or N/A, and an Updated timestamp. You can change FSC %, Payment Terms, Notes, and both policies. You cannot change which customer the row points at and there is no delete button — a config can be edited but not removed from this screen.

Two fallback names appear when a row is not linked to a live organization: Customer # followed by the stored customer number, or Unlinked customer when there is no number either. Those are legacy rows. They still carry terms, but nothing will match them to a billed party, so they are effectively inert.

Configs are created outside this screen too. When you attach a new billing customer while confirming a delivery order, Conterminal creates the config for you with FSC 0, terms 30, and both policies set to Sometimes. Those rows show up here for editing. Creating a config also marks that company as connected to your carrier organization in the companies directory.

Which value wins

Resolution happens when an invoice is generated, and it keys on the billed party — the organization the invoice is billed to — not on the customer named on the delivery order. If a broker or forwarder is the bill-to, the broker's config decides, and the shipper's config is not consulted.

Payment terms: The billed party's Payment Terms wins. If that party has no config row, the organization's Default Payment Terms (Days) is used. If that is missing too, 30. The due date is the invoice date plus the resolved number of days.
Fuel surcharge: Neither setting is applied at invoice time. The invoice's fuel-surcharge total is the sum of the amounts already stored on the charges being invoiced.
Company name, address, prefix, bank, footer: Organization-wide only. There is no per-customer override for any of them, and they are read when the PDF is rendered rather than frozen onto the invoice record.
Freight / Accessorial Customer: Per-customer only. These have no organization-wide default; a party with no config row behaves as Sometimes.

When the billed party has no config row at all, invoice generation records the warning “No billed-party billing config was found for name; default billing settings were used.” That is informational, not a failure — the invoice is still created, using your organization defaults.

How Always / Sometimes / Never are used

When a delivery order is confirmed, Conterminal proposes a bill-to by ranking the parties on the order — customer, BCO, broker, then forwarder in that order — using the policy that matches the charge type. Cartage jobs always use the freight policy.

Any party marked Never for that charge type is removed from consideration, as is any inactive organization.
A party marked Always wins. If more than one is Always, the one that already carries pricing evidence on the order wins; failing that, the earlier role in the list wins.
With no Always, a party carrying pricing evidence wins.
Otherwise the first remaining Sometimes party in role order is proposed. If nothing survives, no bill-to is proposed and you pick one by hand.

A party with no config row is treated as Sometimes for both charge types, so you only need rows for the parties you want to promote or suppress.

Troubleshooting

“Carrier SCAC is required.”

The SCAC field was empty, or held only whitespace. Nothing on the form was saved — the SCAC is checked before anything is written, so fix it and re-submit the whole page.

“Carrier SCAC must contain only letters and numbers.”

The value failed the two-to-ten alphanumeric check. The message names only the character rule, but length triggers it too: a one-character SCAC produces this exact wording. Hyphens, periods, and internal spaces are also rejected. Leading and trailing spaces are stripped and lowercase is uppercased for you, so those are not the cause.

“Company name is required.”

Company Name was blank. The SCAC has already been validated and written by the time this check runs, so a save that fails here may still have replaced your SCAC identifier records. Re-enter the company name and save again.

The customer dropdown is empty

You see “No available customer organizations without a billing config.” The list shows only active, non-carrier organizations that do not already have a config with you — so a company already in the Existing Customer Configs list is intentionally excluded, and an inactive company never appears. If a company you expect is missing from both lists, it is either inactive or not in your workspace at all.

“A billing configuration already exists for this customer.”

A config for that company was created between the moment the page loaded and the moment you submitted — most often by someone else, or by a delivery-order confirm that attached the customer. Reload the page and edit the row in Existing Customer Configs instead of creating a new one.

A customer row shows Cust# N/A

The company has no customer number, so none was recorded on the config. The row is fully usable — terms, FSC, notes, and both policies all work — because matching is done on the organization, not the number. The number is only recorded at creation time and is not backfilled if the company gets one later. It does mean the row will not line up with a customer number in an external accounting export.

A customer row shows “Unlinked customer” or “Customer #1234”

The config is not attached to an organization Conterminal can resolve. These are legacy rows keyed only by customer number. Editing them is allowed but pointless: nothing will match them to a billed party at invoice time. Create a config for the real organization instead.

One invoice shows an unexpected FSC

The fuel surcharge on an invoice is the sum of the amounts stored on its charges, each fixed when that charge was created. Changing Default FSC % or a customer's FSC % afterwards does not restate them. Open the invoice, look at the FSC column per line, and correct the charge rather than the settings.

An invoice came due on the wrong date

The due date is the invoice date plus the terms resolved for the billed party. Check the config for the organization the invoice is billed to, which may not be the customer on the delivery order. If that party has no row, the organization's Default Payment Terms (Days) was used — and if billing settings were never saved, that default is 30 regardless of what the form currently shows.

“You are not authorized to manage billing settings for this organization.”

The database refused the write even though the page loaded. This is a permissions problem, not a form problem, and retrying will not clear it. The customer-billing equivalent is “You are not authorized to manage customer billing settings for this organization.” Send support your workspace name and the exact banner text.

“Unable to save billing settings. Please try again.”

A write failed for a reason other than permissions. Retry once. If it repeats, capture the field you changed most recently — the customer-billing wording is “Unable to save customer billing settings. Please try again.”

“Unable to process the settings request.”

The page was given an error code it does not recognize, usually from an edited or stale URL. Navigate to Billing Settings fresh rather than reloading the URL you are on. The customer-billing wording is “Unable to process the customer billing request.”

The Billing Settings card will not open

It reads “Tenant admin role required.” and is not a link. The card is enabled for tenant admins only, but both pages accept tenant managers, so a manager can open /protected/billing/settings and /protected/billing/customers directly. If the URL also refuses you, your workspace is not a carrier organization or your role is neither tenant_admin nor tenant_manager.