Prepaid Amount vs Amount Due in Structured Invoice Data

A prepaid amount records money already paid against the invoice transaction. The amount due is the outstanding amount requested after the relevant supported reconciliation. These are different from the invoice’s total value. Recording a prior payment should not silently change the quantity supplied or the agreed unit price.

The invoice amount workflow must make this boundary clear: the current creator does not implement prepaid-amount reconciliation or a payment ledger. Its supported total combines line net amounts and tax. Writing a deposit in notes does not make that total subtract the payment.

Separate the sale from its settlement

An invoice can describe a supply worth 600.00 while only 400.00 remains unpaid because 200.00 was already settled. The commercial value and the remaining balance have different roles. Reducing the unit price to 400.00 would describe a different sale rather than transparently recording the earlier payment.

Keep the payment evidence separate from the charge evidence. The accepted order supports the supplied value; a confirmed payment record supports the amount already received. Do not treat an expected deposit, an unconfirmed transfer instruction or a customer’s promise as proof that money was paid.

If a payment covers several transactions, determine the allocation before calculating the balance. The creator does not match bank transactions or allocate receipts across invoices. A note saying “deposit received” is not a substitute for that reconciliation.

Understand a formal reconciliation example

Peppol BIS Billing documents a paid amount and an amount due as separate business terms. Its published reconciliation rule relates the tax-inclusive invoice total, paid amount and rounding amount to the outstanding amount. This is a specific structured rule, not a capability provided by the current creator.

For a simple arithmetic illustration with no rounding adjustment, an invoice total of 600.00 less a confirmed paid amount of 200.00 leaves 400.00 due. The underlying charge still totals 600.00. The example does not establish how a particular advance payment should be taxed or documented.

Where a formal profile is required, the final system needs to map the values into the appropriate fields and satisfy its applicable rules. A sentence displaying the same numbers is readable, but it does not create those typed terms or their validation.

Avoid misleading workarounds

Do not lower a unit price, remove a valid line or add a negative row solely to make the creator’s total equal the unpaid balance. Those changes can misrepresent the supplied value, distort tax or conflict with the accepted agreement. Negative lines are also outside the current positive-invoice model.

A percentage discount is not a payment. Discounts reduce a charge under their commercial basis; payments settle an amount. Converting a deposit into a discount merely to fit the available control changes the transaction’s meaning even if the final number matches.

Likewise, a zero-priced “deposit received” row contributes no deduction. It may create the appearance of reconciliation without actually altering the supported total. Do not deliver a document whose numeric amount requested conflicts with explanatory payment text.

Review payment evidence and allocation

Confirm the currency, amount, receipt date and transaction being settled. A payment in another currency can introduce conversion requirements the current creator does not implement. Keep the appropriate rate and allocation evidence in a suitable accounting workflow.

Check whether the earlier payment belongs to this invoice, a separate advance document or another obligation. The correct treatment can depend on the transaction and applicable requirements. Do not infer it merely from matching customer names or a familiar rounded amount.

If a prior document was issued for an advance, preserve the relationship required by your final process. The current creator does not manage a chain of advance, final and corrective documents or verify that amounts have not been counted twice.

Reconcile in a system that supports the model

The guide to net subtotal, tax and total reconciliation explains what the current numeric total actually contains. Use that to review supported charges, then recognise when settlement information requires a more complete financial model.

If you prepare lines in this creator before transferring them, keep the prepaid requirement explicit in your working records. Finalise in a system that supports prior payments, the correct outstanding amount and any required tax and structured-data representation. Check the resulting output rather than assuming an imported note performs the calculation.

Retain the final charge calculation, payment allocation and delivery version together. The current application JSON, line-item CSV and printable output do not provide formal prepaid reconciliation, legal validation or authority acceptance. Completing the unsupported step in an appropriate system is necessary before presenting the document as a reconciled request for the remaining payment.

In the simple 600.00 example, preserve three distinct review facts: charge value 600.00, confirmed allocation 200.00 and remaining balance 400.00. Check that the payment evidence supports the allocation before using the balance in a final system. If the receipt actually settles another invoice, subtracting it here would understate the request even though the subtraction itself is arithmetically correct.