Prepare advance-payment information by collecting what was agreed, what was actually paid, the relevant dates, currency and document references. Then use software that supports the required document type and amount structure. EInvoiceCreator currently does not implement advance-payment invoicing or reconciliation, so a note or adjusted unit price should not be presented as that functionality.
The document-type preparation workflow starts with the actual business event. A request for an advance payment, confirmation of money received and a final invoice with an outstanding balance are related records, but they are not automatically the same document or calculation.
Distinguish an expected payment from a received one
Read the agreement to identify the proposed deposit or advance arrangement. Separately establish whether payment was received and which transaction it relates to. A request for money does not prove it has been paid, and an account entry needs appropriate reconciliation before it can be treated as payment against a particular invoice.
Keep the agreed amount, actual received amount, currency, date and reference with their sources. If they differ, resolve the difference rather than assuming the agreement’s requested amount equals the bank receipt. The creator does not access bank records or match payments automatically.
For a fictional project, a customer might agree to pay an advance but settle only part of it. The preparation record should preserve that distinction. Do not enter the full expected advance as received simply because it makes the remaining calculation look tidy.
Keep commercial amounts and paid amounts separate
A line price describes the charge for the supplied item under its agreement. A received payment describes settlement of an amount under the relevant process. Reducing the unit price to imitate a received advance can misstate the supply and distort discounts or tax calculations.
OpenPeppol’s published amount model distinguishes an amount paid in advance from the amount due for payment. Its documented payable-amount rule relates the total, paid amount and rounding amount. That is an example of a specific structured model, not a feature of the current creator or a universal instruction for every transaction.
For arithmetic illustration, a confirmed payable total of EUR 1,200 with an applicable received amount of EUR 300 could leave EUR 900 before any other relevant adjustment. Those figures do not establish the proper tax treatment, document timing or representation. The actual process and specification govern those questions.
Preserve document relationships
Collect references to the agreement, advance request, original invoice and final document where relevant. Establish which reference identifies which record. A payment reference used on a bank transfer is not automatically the document number of an advance invoice.
If the process requires a particular correction or replacement of an issued document, obtain appropriate advice and use supporting software. The issued-invoice correction guide explains what to clarify before acting. The current creator has no authoritative issuance or linked-document history.
Keep line relationships where the advance concerns only part of a project or a specific item. An unlabelled paid amount without context can be difficult for another operator to allocate. The preparation sheet should show the intended relationship without inventing a mapping the current model lacks.
Confirm tax and timing separately
Advance payments can raise questions about invoicing, tax timing and the final document that depend on applicable rules and facts. Do not infer the answer solely from the existence of a bank receipt or an agreed deposit percentage. Supply the relevant information to an appropriate adviser where necessary.
Ask what category, rate, wording, dates and document references need to be represented. Record the answer clearly enough for the final software operator. A general “deposit checked” note can leave the actual required fields unresolved.
The current tax inputs record manually confirmed information. They do not determine advance-payment treatment or calculate a full tax reconciliation between earlier and final documents. Adding a zero-priced line or a discount does not implement that missing structure.
Recognise the current output limit
EInvoiceCreator calculates totals for ordinary positive invoice lines, with supported line discounts and manually entered tax values. It has no dedicated paid-amount field or advance-payment reconciliation. Its preview therefore should not be treated as an authoritative outstanding-balance calculation for an unsupported scenario.
Application JSON carries the application’s own model, and CSV contains line items. Neither becomes a prepayment-standard export because a user puts an amount or reference in notes. Printable text can preserve a human explanation without satisfying the final structured fields.
If the actual transaction requires this workflow, retain the source data and choose suitable supporting software before producing the final customer document. Do not change economic facts to make the ordinary form accept a simplified substitute.
Review the external result against evidence
When a capable system generates the document, compare agreed charges, confirmed payments, relevant dates, tax information, references and outstanding amount with the source records. Inspect the actual file and applicable validation results rather than relying only on the displayed total.
Keep payment reconciliation evidence separate from document-generation evidence. A calculated balance does not prove a payment was received, and a valid structured file does not prove recipient acceptance. Clear preparation gives the next system the facts it needs while preserving what still requires confirmation.