Mapping: Customer Account, Line Item, Clearing

Customer + company code is the customer account, company code · document · fiscal year · line is the line item — and a partial payment is a new document.

The debtor is customer + company code

Payment term, dunning block, reconciliation account, and accounting clerk are tied to A_CustomerCompany and therefore to the company code; from a commercial standpoint, the same customer in two company codes is two different things. The customer without a company code is the umbrella above them.

Bilendo	SAP	Rule
`customer_number`	`Customer` + `CompanyCode`	concatenated
`external_parent_id`	`A_Customer.Customer`	Umbrella across the company codes
`customer_name_1` … `customer_country`	`A_BusinessPartner` / `A_BusinessPartnerAddress`	Default address, country ISO-2
`external_payment_term`	`A_CustomerCompany.PaymentTerms`	Key
`dunning_stop`	`A_CustomerDunning.DunningBlock`	Dunning block on the debtor
`imported_reminder_stage` / `imported_last_reminder_date`	`A_CustomerDunning.DunningLevel` / `LastDunnedOn`	only during the initial extraction — after that, Bilendo manages the level
Custom field “Dunning procedure” (mapped)	`A_CustomerDunning.DunningProcedure`	→ Bilendo dunning area
Custom field “Head office”	`A_CustomerCompany.CustomerHeadOffice`	populated = dunning is sent to the head office
Custom field “Reconciliation account” / “Accounting clerk”	`ReconciliationAccount` / `AccountingClerk`	the structure the customer itself works by

Head office, alternative payer, and alternative dunning recipient are passed along as separate fields and are NOT resolved: who pays whom is a decision for the dunning strategy, not for the collector.

The open item

Identity in Bilendo: Company code · Document number · Fiscal year · Posting line. The fiscal year is part of it because document number ranges run per fiscal year. An item that is delivered again is updated.

Bilendo	SAP (A_OperationalAcctgDocItemCube)	Rule
`receipt_number`	`AccountingDocument`	Key component
`company_code`	`CompanyCode`	Key component
`fiscal_year`	`FiscalYear`	Key component
`external_position`	`AccountingDocumentItem`	Key component
`imported_customer_number`	`Customer` + `CompanyCode`	concatenated like the customer account number
`invoice_number`	`DocumentReferenceID`	XBLNR — the invoice number from the customer's perspective
`receipt_date` / `external_creation_date`	`DocumentDate` / `PostingDate`	Posting date is a delta anchor
`due_date`	`NetDueDate`	Net due date; cash discount dates are carried alongside as custom fields
`amount` / `currency`	`AmountInTransactionCurrency` / `TransactionCurrency`	Sign derived from `DebitCreditCode`
`external_doctype`	`AccountingDocumentType`	BLART → customer's mapping table
`external_doctype_hint`	`PostingKey`	distinguishes invoice, credit memo, and payment within a document type
`erp_association`	`AssignmentReference`	ZUONR — the link for payments without clearing
`dunning_stop`	`DunningBlockingReason`	Bilendo doesn't dun what SAP blocks
`delete_indicator`	`IsReversed` / `ReverseDocument`	Reversal withdraws the item
`special_ledger_indication`	`SpecialGLCode`	populated = down payment, guarantee, memo item → not delivered
— (do not deliver)	`FinancialAccountType` ≠ `D`	except within the scope of accounts payable

Clearing

Hard clearing: the item travels again in the next delta with external_clearing_number1 (ClearingAccountingDocument), external_clearing_date and fully_cleared_indicator from IsCleared. Bilendo replaces it; it leaves the dunning run.
Reversal of a clearing: ClearingIsReversed — the item comes back without clearing fields and is reopened. This is a dedicated field; nothing has to be guessed here.
Residual item creation: the payment clears the original item and posts a new one for the remainder. InvoiceReference + InvoiceReferenceFiscalYear + InvoiceItemReference point to the original and travel along as erp_reference — otherwise Bilendo ends up with two unconnected receivables.
Partial payment without clearing: the receivable and the payment share the assignment number; Bilendo offsets them to a remaining amount of 0.
Direct debit: an item in collection is not overdue — PaymentMethod plus HasPaymentOrder means a dunning block until a returned direct debit arrives.

Which of the two partial-payment models applies to you is the question where a wrong assumption immediately produces wrong amounts — that's why it appears in the "Business Decisions" question catalog.