> ## Documentation Index > Fetch the complete documentation index at: https://docs.alforse.com/llms.txt > Use this file to discover all available pages before exploring further. # 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. Alforse manages them in separate modules with different fields and workflows. ## Suppliers A supplier lives in purchasing and anchors the buy side: purchase orders, supplier quotes, 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 conversion factor 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, Alforse 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. NOTE 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: quotes, orders, and invoices 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. NOTE 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 RFQs through a digital-quote link; customers track their orders through a [customer portal](/docs/reference/customer-portal.md). ## 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 Alforse moves money from them; a person reads the details and enters them in their own banking system. [![Customer Bank Accounts tab listing two Indian accounts, one in USD and one in INR, each showing a masked account number with its IFSC and SWIFT codes](/screens/reference-bank-accounts.png)](/screens/reference-bank-accounts.png) Currency, bank, and country sit on every row, so two accounts at different banks stay distinguishable without opening either. 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 IBAN already identifies the bank. Pick India and you get an **"IFSC Code"** field plus a required SWIFT / BIC, because one routes the payment inside the country and the other gets it there. FieldType
**Name**required Your label for the account, so two accounts at one bank stay distinguishable.
**Account Holder** Only needed when it differs from the party's own name.
**Bank Name**required The bank the account sits with.
**Bank Address**required Printed onto payment files; correspondent banks route international wires on it.
**Country**required Selects which validation rules apply to everything below.
**Currency** The currency the account settles in.
**Account Number / IBAN**required Labelled by country. Validated by checksum where the scheme has one.
**Routing code**required Named for the country: *Routing Number (ABA)*, *Sort Code*, *BSB*, *IFSC Code*, or *Transit & Institution*. Absent for countries whose IBAN carries it.
**SWIFT / BIC** Required wherever the country expects a cross-border payment to route.
**Notes** Free text for anything the fixed fields do not cover.
HEADS UP **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. NOTE **Validation proves the format, never the owner** A checksum confirms an IBAN 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](/docs/reference/documents.md), so you can find it either by opening the party or by searching. [![Customer Documents tab listing two uploaded files with their size and upload date, above the drag-and-drop area](/screens/reference-party-documents.png)](/screens/reference-party-documents.png) Files filed here belong to the party, not to any one order. ## Related **Approvals** A new supplier can be held at Pending until approved. [Open](/docs/reference/approvals.md) This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.