Importing Customers: What a Row Overwrites
A File Import row on Customer Maintenance does not only add customers: it overwrites the record it matches, and a row without a customer code can match a supplier or an employee. Read this before you import into a customer list that already holds records. You are here: this page follows Duplicate Customers, because an import is one of the ways two records become one without anybody running a merge.
What a File Import row matches, and what it overwrites
Importing updates as well as creates, and the customer code decides which records a row can reach. Each File Import row is first matched against the records you already hold, and a row that matches overwrites that record with the values it carries:
| The row carries | It is matched against | When it matches |
|---|---|---|
| A customer code | That code only | The record is updated. A code nobody holds creates a new customer, even when the same business is already in your master as a supplier |
| No customer code | Every record you hold that is not deleted, suppliers and employees included: ID number, then tax registration number, SST number, e-mail, phone. The first that finds a record wins, and the newest such record is taken | The record is updated and made a customer. A supplier that shares a phone number or e-mail with the row is enough |
- The row’s AR/AP type replaces the record’s, and a blank one is refused. The check stage refuses a row whose
AR/AP type is blank (ARAP TYPE is Invalid), and one refused row stops the whole file. A customer sheet that says
AR_TRADEon every row, imported over a customer-and-supplier record set toAP_TRADE, resets it, and its next purchase document posts to the receivable account (The AR/AP type is decided once). - The row’s ID type and ID number are copied into the E-Invoice tab’s ID type and value, replacing what the tab held.
- The row’s address is added as a billing or shipping address, and ticked as the default e-invoice address when the row carries a TIN. An address identical to one already on the record is not added again.
Symptom: after an import, an existing walk-in customer has a new name, a supplier or an employee now
appears in the customer listing, or a debtor’s AR/AP type has changed. Cause: a row without a code matched
the record on a shared phone number or e-mail, or carried a different AR/AP type. A supplier made a customer this
way is also given the sheet’s AR/AP type — AR_TRADE on a customer sheet — so its next purchase document posts to
the receivable account.
Prevention: when you import into a populated customer list — GadgetSphere’s runs to about 85,000 records, most of them walk-ins — give every row a code, and set each row’s AR/AP type to what that record should post to.
Your tenant may match on a different list. A tenant’s configuration can hold a matching rule for the customer import, and the import screen does not show it. Where one is set, every row is matched on the fields that rule lists, in its order, instead of the order above, and the customer code counts only if the rule names it — so a row with a code can still overwrite a record that shares its e-mail or phone.
If an import matches records the table above says it should not, ask BigLedger whether your tenant has a rule before you import again.
Related documentation
- Customer Maintenance: the File Import menu, the other imports and uploads, and what a save checks.
- Duplicate Customers: deciding which records are one person, and merging them.
- The AR/AP type is decided once:
why a supplier reset to
AR_TRADEposts its purchases to the receivable account, and how you find out.