Import payments and verify matching to customer invoices

Objective. Import bank payments reliably, match each valid line to the right customer and invoice, isolate duplicates and unknown identifiers, explain partial balances and retain evidence for reminders, reporting and accounting exports.

ProfileAccountingLevelAdvancedTypeControlEstimated duration55 minData usedPayment files, customer movements, matching, balances, banks and pre-import controls

Before you start: prepare your subscription mappings

Before importing, record the company code, payment-method code, bank and two customers with open issued invoices from your subscription. Work on a copy of the CSV and replace teaching codes with those actual values. If you may not create payments, complete the checks and mapping and stop before confirmation.

Continue when company, method, bank and customer values in the working file match active reference data in your subscription.

Teaching batch to review

Download the batch to review and keep the accepted batch for the final reconciliation. It contains transactions dated 20 July 2026: VIR-101, EUR 1,200.00 for customer code ALPHA (the synthetic ALPHA CONSEIL record) and F2026-101; VIR-102, EUR 400.00 for BATIS and invoice F2026-102 of EUR 600.00; and VIR-103, EUR 250.00 with unknown customer ZZ999. A fourth row deliberately repeats VIR-101. The expected calculation is one exact payment clearing F2026-101, one partial payment leaving EUR 200.00 on F2026-102, and no creation for the unknown customer or duplicate. Execute the import only after an authorised test base has been prepared with these references.

CSV column	Tempolia field	Check before import
societe	Company	Code 001 in the file — replace it with your company code
mode	Payment method	Code 05 — Virement (bank transfer) title
banque	Bank	BNK01 in the prepared database
date	Creation date	20 July 2026
reference	Document number	VIR-101 to VIR-103, unique in history
client	Customer	ALPHA, BATIS or ZZ999 code
facture	Not imported	Control reference retained for matching after import
montant	Gross total	Positive amount reconciled to the bank statement

Prerequisites

In your working copy, replace company, bank and payment-method codes with active values from your subscription.
F2026-101 and F2026-102 must be created, issued and open before execution; otherwise complete the mapping and arithmetic without importing.
Keep the original teaching file unchanged and identify the batch by VIR-101 to VIR-103.
Use your subscription only with authorisation to create payments, a controlled working folder and a documented recovery procedure. No accounting file is transmitted to production.

55-minute schedule

8 min: verify invoices and opening balances.
12 min: load the file and map fields.
12 min: isolate the unknown customer, duplicate and partial payment.
10 min: import the corrected batch and verify created lines.
8 min: match the two valid payments and check balances.
5 min: reconcile the export and assemble batch evidence.

Observable checkpoints in the prepared test

The mapping uses codes 001 and 05, sends reference to Document number and montant to Gross total. The facture column is not imported; it guides matching after the payments are created.
VIR-101 exists once and clears F2026-101.
F2026-102 retains exactly EUR 200.00 after VIR-102 is matched.
ZZ999 remains in the anomaly log or source to correct; it is never assigned to a similar customer.

Understand import, payment and matching as separate stages

The bank file proves what the bank reported. The imported payment proves what Tempolia recorded. Matching proves which invoice or credit note the amount settles. These three statements are related but not interchangeable. A row can be syntactically imported and still be functionally wrong because the customer, company, bank, sign or reference is incorrect.

A stable bank reference is the first duplicate barrier. Search it in prior imports and manual entries, within and beyond the current period. A matching customer name is weaker than an identifier and must not justify an arbitrary assignment. Unknown or ambiguous lines remain outside the validated batch until the source is corrected.

Partial payment is not an error. It is a legitimate state that must remain visible: F2026-102 of EUR 600.00 minus VIR-102 of EUR 400.00 leaves EUR 200.00. Matching should explain that remainder, not invent a discount. A grouped payment may match several pieces, but every allocation must reconcile to the original bank amount.

Capabilities acquired

Freeze the import perimeter by company, bank, period, format and unique batch references.
Map required columns and distinguish source data, reference data and derived matching.
Detect a duplicate across the current file, earlier batches and manual payment entry.
Reject an unknown customer without attaching the payment to a similar name.
Import valid lines once and reconcile their count and total with the corrected source.
Match exact and partial payments while keeping unexplained amounts visible.
Verify reminder, PA/eReporting and accounting-export consequences without confusing their roles.

1. Establish the opening state and map the file

Path: Billing > Payments, Tools > Import, and the sales journal.

Filter the issued invoices and verify that F2026-101 is EUR 1,200.00 open and F2026-102 EUR 600.00 open. Search VIR-101, VIR-102 and VIR-103 in the payment table before import. Record zero existing occurrences as evidence. Then load a copy of the file and select the customer-payment import type.

Map company code 001, payment-method code 05, bank BNK01, 20/07/2026 creation date, reference to Document number, customer code and montant to Gross total. Leave facture unmapped: it is the control reference for matching after import. Preview all four rows. A generic import page or a preview without the case references is not evidence. Do not validate while duplicate VIR-101 and ZZ999 remain in the accepted population.

Customer-payment import form with a non-imported preview mapping the CSV headers to Tempolia fields — The preview maps the real headers without uploading the file or creating a payment. It guides the operation; the four-row batch and its two accepted payments still require a separate result screen.

Issued-invoice journal showing customer, reference, date and gross amount — Select two open issued invoices from your subscription and copy their references into the controlled working file.

2. Resolve anomalies before writing data

Classify each preview row. VIR-101 is valid once; its duplicate is excluded using the stable reference and source-row trace. VIR-102 is valid even though it will be partial. VIR-103 is rejected because ZZ999 is unknown. Correct the source identifier only from authoritative information; never select ALPHA CONSEIL or another customer because the name appears plausible.

Prepare a corrected two-row import file or an explicitly controlled accepted selection, according to the active import flow. Preserve an anomaly log containing original row, reason, decision and responsible person. Reconcile the accepted total: EUR 1,200.00 + EUR 400.00 = EUR 1,600.00. The rejected EUR 250.00 is not lost; it remains pending correction outside the imported total.

Payment table showing references, customers, bank, dates, amounts and statuses — Search the two accepted references and verify customer, bank, date, amount and unique occurrence.

Payment-method setup showing code 05 with the title Virement (bank transfer) — The screen confirms that code 05 means Virement (bank transfer). Use 05 in the CSV; the title alone is not an import code.

3. Match exact and partial payments

Path: Billing > Customer movements.

For ALPHA CONSEIL, select VIR-101 and F2026-101. Check equal and opposite signs, same company and EUR 1,200.00 before matching. The group must total zero and receive a traceable matching reference. For BATIS, select VIR-102 and F2026-102. Confirm that the payment is EUR 400.00 and preserve the EUR 200.00 open balance.

If F2026-102 appears cleared, inspect other matched movements, signs and amounts; do not add a miscellaneous movement. If matching is unavailable, verify status, customer and company. If a payment was attached to the wrong customer, use the authorised correction flow and retain history instead of compensating it with another false entry.

Customer movements showing invoices, payments, matching and remaining balances — For each accepted payment, verify the matched invoice and calculate the remaining balance.

Movement detail used to explain the EUR 200 residual balance — The residual amount remains visible until a real future payment or authorised event clears it.

4. Reconcile downstream uses and evidence

Review reminders after matching: F2026-101 must not be selected, while F2026-102 may remain for EUR 200.00 according to its due date and dispute status. In the accounting-export preview for the selected period, verify the two accepted references, your adapted company and bank codes, and the EUR 1,600.00 teaching total. Do not transmit the file.

If payment reporting to PA/eReporting applies, inspect the relevant history separately. Its absence or status does not change the bank-import proof. Reconcile the corrected CSV, import result, payment table, matching groups and export selection. Store batch name, source checksum or retained file reference, date, operator, accepted count, rejected count and totals so another person can repeat the control.

Reminder preparation screen showing company, customer and matter filters — This screen defines the reminder population; it does not display or prove a synthetic EUR 200 residual.

Accounting export form showing software, company, journal and period controls before generation — This is configuration evidence only; generated rows are still required to prove the accepted payment batch.

Payment reporting history consulted separately from bank import evidence — A real history row is required; an empty table is not proof of reporting.

Guided practice and diagnosis

1. Prove the two invoices are open and the three bank references absent before import.
2. Map four source rows, exclude duplicate VIR-101 and ZZ999, then import two valid rows totalling EUR 1,600.00.
3. Match VIR-101 exactly, VIR-102 partially and reconcile balances and accounting preview.

F2026-101 is cleared by the single EUR 1,200.00 VIR-101.
F2026-102 stays open for exactly EUR 200.00 after VIR-102.
Neither ZZ999 nor duplicate VIR-101 creates a validated payment.

Diagnosis

A duplicate reference requires searching earlier batches and manual entries before any new import.
An unknown customer is corrected in the authoritative source, never assigned by name similarity.
A cleared F2026-102 requires checking amount, sign and all other matched movements.
A missing export line requires checking company, bank, date, method, status and export selection rules.

Payment list showing references, amounts and export eligibility — Filter to the selected period and reconcile accepted payment count and total before accounting export.

Common mistakes

Treating a row read by the importer as a reliable payment.
Using a customer name guess to resolve an unknown identifier.
Importing a partial payment and then forcing the invoice to clear.
Running the same batch again because the screen result was not documented.
Sending reminders or accounting exports before unmatched payments have been reviewed.

Before you finish

Present a control sheet containing four source rows, two accepted rows for EUR 1,600.00, two rejected rows, one cleared invoice and one EUR 200.00 residual balance. A colleague must be able to locate each amount in the prepared source, payment table, matching view and export selection.

The downloaded references remain teaching values until you adapt and import the working copy; verify only the references that were genuinely accepted in your subscription. The real-data transfer must be documented separately and must stop if the required rows are absent.

Step back

Payment import is a reconciliation process, not a file-loading task. Automation can validate formats, required fields, duplicate references and arithmetic totals; human review must resolve identities, business meaning and exceptions. The most useful long-term indicators are duplicate attempts, unknown-customer rows and imported payments still unmatched after the expected processing delay.

Operational hand-off

For every batch, retain the original read-only file, corrected working copy, mapping version, accepted and rejected counts, accepted total, anomaly decisions, operator and import time. Give the reconciliation to a second reviewer who did not perform the import. That reviewer must locate VIR-101 and VIR-102 in the bank source, payment table, customer movements and export preview, then confirm that VIR-103 remains unresolved rather than being silently discarded. Schedule a daily review of imported-but-unmatched items and an alert on a bank reference seen twice. This turns the exercise into a repeatable control rather than personal knowledge.