Before sending an invoice, compare its payment section with the accepted terms and authorised instructions. Check the method, due date, amount, currency, destination and reference together. A document can contain individually plausible values that contradict one another when read as a payment request.
Use this checklist after the payment preparation workflow. It is a practical review of supported information, not proof of account ownership, legal approval or successful settlement. The creator does not process payments or track whether the recipient has acted on the instructions.
Check the commercial agreement
Confirm what the customer agreed to pay and when. Use the accepted quote, order or later authorised amendment, not a familiar sentence copied from another customer. Identify any conditions that change timing or the amount being requested.
Read the invoice’s due date beside written terms. If they conflict, resolve the actual agreement before export. The app checks supported calendar rules but does not interpret every contractual phrase or determine statutory payment rights.
If settlement is staged or conditional, identify whether the current single-date model can represent it accurately. Do not hide a required schedule or unsupported balance calculation in notes while leaving a contradictory full-amount request in the main document.
Check amount and currency
Compare the total with the reviewed line calculation and the agreed invoice currency. Read the currency code with the number. Changing the selector does not convert the amount or establish that an account can receive that denomination.
Do not use unit-price changes or discounts to simulate a prior payment. The creator has no prepaid reconciliation or account ledger. If the correct amount due depends on unsupported financial features, finalise in a system that implements them.
Check any written amounts in payment text and notes. The live numeric preview updates when supported inputs change, but prose does not. A sentence containing the old balance can survive a correct recalculation and confuse the recipient.
Check the authorised destination
Compare account details with the confirmed source instruction. Review critical identifiers fully and retain their labels. A plausible format or matching account name does not prove ownership or authorisation.
Use the bank-detail review process for the separate source, transcription and consistency checks. Unexpected changes need the appropriate trusted confirmation process; the creator cannot authenticate the instruction or verify its sender.
Where the payee differs from the seller, keep the roles distinct. Confirm the authorised arrangement and any final-format requirements. Do not replace seller identity with payment-recipient information merely to make the names appear consistent.
Check the reconciliation reference
Confirm which value the customer should reproduce with payment and how it identifies this invoice. Keep buyer procurement references separate unless the agreed process deliberately uses one as the payment reference.
Search repeated text for a previous invoice’s reference. Updating the supported field does not rewrite copied notes. Avoid unnecessary duplication, and compare any essential repeated value explicitly with the primary instruction.
The creator does not check reference uniqueness against past invoices or incoming bank receipts. Use the appropriate business records to establish whether the value is suitable and keep the intended final version identifiable.
Check privacy and readability
Remove passwords, authentication values, unnecessary personal details and internal commentary. The invoice may circulate beyond the purchasing contact. Local processing does not protect information once it is included in a file you share.
Inspect the preview and intended print output for long account identifiers, ambiguous labels and contradictory blocks. Do not use arbitrary spacing that makes a value difficult to copy accurately. Keep the information readable without changing its confirmed meaning.
Review application JSON if it is part of the handoff. A screen view is not proof that every exported field has been inspected. Line-item CSV is not a complete payment instruction document and should not be presented as one.
Assign any remaining external actions
Identify who performs delivery, formal mapping, payment collection and receipt reconciliation where required. A note asking for remittance advice does not send a message, and a direct-debit label does not create a mandate or schedule collection.
If the destination requires typed payment fields or codes, use software that implements the correct profile and version. Inspect the actual mapped output and validation evidence rather than assuming a readable paragraph satisfies the requirement.
You can revise the supported payment section locally, rerun field checks and create a fresh printable or application-data export. Earlier downloads retain their previous values, so distinguish them from the intended final file and follow the appropriate process if an old version was shared.
Retain the accepted terms, authorised instruction, review scope and final output under your business process. A useful final check establishes what was reviewed and which actions remain. It does not claim that the creator verified banking facts, transmitted a standards document, confirmed payment or guaranteed recipient acceptance.
A practical final check
Record the exact reviewed file name and revision so the check remains traceable after another draft is exported.
If another person edits the draft after review, repeat the affected checks against the new exported version.