Suppliers & customers
The parties you buy from and sell to, and the ways their records differ.
Suppliers are parties the company buys from; customers are parties it sells to. Carbon manages them in separate modules with different fields and workflows.
Suppliers
A supplier lives in purchasing and anchors the buy side: , , and bills all reference it. Its status is a fixed set: Active, Inactive, Pending, Rejected. A supplier links to the items you buy through supplier parts, each carrying the supplier's own part number, a minimum order quantity, and a from their pack to your stock unit. The supplier's Parts tab lists every supplier part that names it, with each price in its own currency, and a search box filters the list by part number, name, or the supplier's part number. New adds one by picking a purchased item, and opening a row edits it in place. The same records can be added from the item's Purchasing tab.
A supplier part's unit price and its price breaks are stored as the supplier quoted them: per purchase unit, in the supplier part's currency. A new supplier part takes the supplier's currency, and you can change it. When the price lands on a purchase order or bill, Carbon converts it into the document's currency at the current exchange rate. A price already in the document's currency is used exactly as entered. Quote costing converts the same price into your base currency per stock unit.
A supplier part has no lead time — purchasing lead time is set per item, not per supplier-part. The supplier part is about identity and pack size, not delivery time.
Customers
A customer lives in sales and anchors the sell side: , orders, and reference it. Unlike supplier status, customer status is a configurable list you define, not a fixed enum. Customers don't have a supplier-part analog; pricing instead comes from price overrides and pricing rules, which can target a whole customer type and stack with quantity breaks.
The asymmetry to remember: supplier status is a fixed four-value set; customer status is a company-configurable lookup. Their type catalogs (supplier type, customer type) are both user-defined.
What they share
Both records carry the same satellite shape: contacts, locations/addresses, and payment, shipping, and tax defaults. Payment terms, currency, and tax settings live on those satellites, not on the core record. Both also have a human-readable id (SUP… / CUS…) on top of their internal key, and both can expose an external portal: suppliers respond to through a digital-quote link; customers track their orders through a customer portal.
Bank accounts
Both parties can carry bank accounts: the account you pay a supplier into, and the one you refund a customer to. They live on the Bank Accounts tab of the record, and they are reference data. Nothing in Carbon moves money from them; a person reads the details and enters them in their own banking system.
The fields adapt to the account's country, because banking identifiers are not the same everywhere. Pick France and the account field is labelled "IBAN" with no routing field, since an already identifies the bank. Pick India and you get an "IFSC Code" field plus a required , because one routes the payment inside the country and the other gets it there.
Bank details sit behind accounting permissions, not purchasing or sales
Most people who can open a supplier should not see its bank account, so the tab is gated on accounting rather than the module that owns the record. Without accounting view permission the tab does not appear in the sidebar, and opening its URL directly is refused. Adding, editing, and deleting are gated separately.
Account numbers display masked, showing the last four characters with a toggle to reveal the rest. That deters someone reading over your shoulder or catching it in a screenshot; it is not an access control, and the permission above is what actually protects the data.
Validation proves the format, never the owner
A checksum confirms an was typed correctly. It cannot tell you the account belongs to the supplier you think it does. Confirming that is an out-of-band step, a call to a number you already had, and it is the control that stops payment-redirection fraud.
Documents
Both records have a Documents tab for files that belong to the party itself rather than to one transaction: a W-9, an insurance certificate, a signed master agreement. Drop a file on the tab and it is filed against that record, and it also appears in the shared document library, so you can find it either by opening the party or by searching.