Radix-Skills/skills/data-science/erp-data-reconciliation/references/coop-invoice-payment-allocation.md

Coop fakturaliste + Uniconta betalingsfordeling workflow

Session-derived pattern from the Coop-Uniconta project: simplify reconciliation by using three forward-looking sources instead of many historical exports.

Target workflow

Use these files as the primary operational import set:

1. Coop invoice list (Coop Fakturaer YYYY.xlsx) — all invoices/credits issued to Coop.
2. Uniconta payment allocation / debtor ledger (Coop Debitor YYYY.xlsx) — invoice and settlement/payment lines.
3. Coop Payment_advice — later bridge source for explicit settlement detail.

This supports the user question: “Mangler Coop at betale nogle fakturaer?”

Models / concepts

Recommended separate models, not generic postings only:

CoopInvoice

• source file, fiscal year/accounting year
• date
• account number/name
• customer reference (Deres ref)
• order number
• invoice number
• requisition
• total, net, VAT amounts
• payment terms / sent dates if present
• raw row JSON + sheet/row reference

PaymentAllocationLine

• source file, fiscal/accounting year
• date
• account
• invoice number
• voucher/document number
• posting number
• text
• debit, credit, VAT
• physical voucher/origin/account type/debtor-creditor/name
• is_payment_line boolean
• raw row JSON + sheet/row reference

Payment-line detection

In Uniconta debtor/payment allocation files, not every line is a payment. They may contain both original invoice postings and later settlement lines.

Observed signals for payment/settlement lines:

• Bilag != Faktura
• text contains Coop 0010014808
• text contains Omp. Coop

Do not infer paid status from invoice existence alone; calculate it from settlement/payment lines linked by invoice number.

Invoice payment status algorithm

For each CoopInvoice.invoice_number:

1. Find PaymentAllocationLine rows with same invoice number.
2. Sum payment/settlement effect from rows marked is_payment_line.
3. Compare against CoopInvoice.total_amount.
4. Emit status:
   • paid: residual within tolerance
   • partial: some payment but residual remains
   • open: no settlement/payment lines found
5. Keep explanatory fields: payment vouchers, dates, amount paid, residual, source rows.

Use Danish accounting display, but ISO dates and Decimal internally.

Bank reconciliation with allocation groups

Use the payment allocation as an explanation layer between bank deposits and invoices:

Bank payment → allocation group/voucher → multiple invoice lines → Coop invoices

This is especially useful when one bank deposit equals many invoices/credits. Build groups by voucher/payment text/date and compare the group total to the bank payment.

Employee expense exception

Negative bank postings whose text indicates purchases at Coop/Kvickly may be employee expenses, not Coop customer payments. Treat them as ignored/out-of-scope only when the user confirms the business meaning. In the Coop-Uniconta project, two negative bank lines with Coop/Kvickly text were confirmed as employee outlays and excluded from relevant bank coverage.

Implementation pattern:

• keep ignored bank payments visible in reports
• do not count them as unmatched customer-payment differences
• report both total bank count and relevant bank coverage percentage

UI/reporting shape

Add a dedicated invoice-payment view or dashboard section:

• paid invoices
• open/different invoices
• total invoices
• open residual amount
• status badges: BETALT, ÅBEN, DIFFERENCE, FAKTURAER
• filters for year, customer/account, amount, residual, status
• export of open/difference invoices to Excel/CSV

Minimum tests

Add tests for:

1. A Coop invoice is marked paid via matching Uniconta payment allocation lines.
2. Partial/open invoices calculate residual correctly.
3. Confirmed Coop/Kvickly employee expense bank lines are ignored but still reported.
4. Relevant bank coverage is 100% when all customer-payment bank lines are explained and only confirmed out-of-scope lines remain.

Pitfalls

• Do not hardcode confidential file paths or sample data into committed code.
• Keep raw Excel/source folders gitignored.
• Do not collapse invoice list, payment allocation, and payment advice into one generic parser; their semantics differ.
• Payment advice parser can be added later, but wire the import type early so UI/workflow is ready.