Invoice pre-flight check

A pre-flight check on a draft invoice returns a hold that names the defect, or it returns nothing. Those are the only two useful outcomes for a billing lead.

Hold when the draft disagrees with the purchase order, when a required field is blank, or when the currency does not match the customer master or the PO. The citation has to name the field, the value on the draft, and the value on the PO or master. Billing should be able to open the invoice, fix that item, and send. A note that says the invoice "looks off" is not a hold.

When the draft is complete and aligned, the result stays empty. Empty means send. Do not invent a reason to pause a clean invoice. Holding a complete invoice is a failure: it creates a review cycle with nothing to correct, and the next real mismatch gets treated as noise.

Billing still owns the send. The check does not transmit, void, or rewrite the invoice. It attaches a cited hold or it leaves the hold blank.

Run this after contract-to-invoice generation, once a draft already exists. Generation creates lines. Pre-flight asks whether those lines are safe to send.

Compare the draft to two sources: the purchase order, when the account is PO-controlled, and the customer master for bill-to, currency, and required fields.

On the PO, confirm the PO number is present and matches an open PO, that bill-to and ship-to agree when the PO names them, that line quantities and unit prices sit inside the tolerance your team already uses, that remaining unbilled quantity can cover the draft so you do not overbill a closed or exhausted line, and that currency matches. On the customer master, confirm the invoice currency matches the customer's invoicing currency, that registration fields required for that customer are populated (rate and jurisdiction belong in tax and jurisdiction assignment, not here), and that a PO is present when the master marks the account as PO-required.

The draft may sit in Workday, SAP, Salesforce, Tabs, or another billing system. The comparison does not depend on the brand of the ledger. Pull the draft, pull the PO and the master, write a hold or write nothing.

Do not use the model to mint a PO number because the field is empty. A missing PO on a PO-required account is a cited hold. A guessed PO that looks plausible will pass the check, reach the customer, and come back as a rejection. That is worse than stopping the send.

A billing specialist opens a draft for a US customer whose master currency is USD and whose open PO is PO-44182, with 10 units remaining at 120 USD. The draft shows 10 units at 120, currency EUR, PO field blank.

The check should hold. The citation names two defects: draft currency EUR does not match customer master USD (the PO is USD as well), and the PO number is missing on a PO-required account. The check does not write PO-44182 onto the draft. Billing enters the PO, switches currency to USD, re-runs the check, and sends when the hold is empty.

If that same draft already had PO-44182, USD, 10 units at 120, and a complete bill-to, the hold stays empty. Adding a third issue because the line description is not a verbatim copy of the PO text is holding a complete invoice.

If the check is skipped and the EUR draft goes out, the customer rejects on currency and on the missing PO. Sending past a mismatch is the other failure: the invoice leaves with an error the comparison already had the data to catch.

That rejected invoice shows up later in dispute-likelihood scoring and in cash application via remittance parsing when the customer short-pays or refuses the line. Catching it on the draft is cheaper than either of those steps.

A usable hold cites the field, the draft value, and the expected value from the PO or master.

These citations work:

• Missing field: PO number is blank; customer master requires a PO.
• PO mismatch: draft PO PO-44001 does not match open PO PO-44182.
• Currency error: draft currency EUR; customer master and PO are USD.

A hold that only says "review before send" forces billing to re-run the comparison by hand. That is the work the check was supposed to do.

When several defects exist, list them. Do not collapse them into one vague flag. Billing should clear the hold by fixing each cited item, then re-running the check. The second pass returns empty if the fixes are real.

Never edit the draft inside the model. No invented PO, no silent currency swap, no quantity change the specialist did not approve. The hold is a stop, not an edit.

Holding a complete invoice. The draft matches the PO and the master, required fields are populated, currency agrees. A cautious run still emits a hold because a description differs in wording, or because a tax line is present and the model is unsure. Review the empty case on purpose. If a reviewer cannot point to a missing field, a PO mismatch, or a currency error, the hold should not have fired.

Sending past a mismatch. The comparison found EUR versus USD, or a PO number that is not on the open PO, and the workflow still allowed send because the hold was a comment, a log line, or optional. Treat a cited hold as blocking until billing clears it. If the stack in Workday, SAP, Salesforce, Tabs, or elsewhere only supports a note on the draft, the operating rule is the same: no send while a pre-flight hold is open.

Inventing a PO number. The field is empty, the account is PO-required, and the model copies a recent PO from another invoice or from a similarly named customer. The draft then looks complete and will not hold. The customer rejects it. Keep identifier generation out of this step. Missing stays missing and cited.

Related PO mistakes belong in the same bucket. Matching the wrong open PO when the customer has several, treating a closed PO as valid because the number string matches, or ignoring remaining quantity and overbilling a line the PO already exhausted are still PO mismatches. Cite remaining quantity or closed status. Do not invent a new PO to make the draft look clean.

Billing sends. A clean pre-flight means the invoice is complete and consistent with the PO and the master. It does not decide commercial timing, credit, or whether the customer should be billed this week.

After send, cash still has to land. Remittance that fails because the invoice should never have gone out is a pre-flight miss, not a cash-application miss. Keep the two jobs separate.

When you change PO tolerances, required-field rules, or which accounts are PO-controlled, update those sources. Do not ask the model to improvise. Hold language should stay specific: field, draft value, expected value. Specific holds get fixed. Vague holds get ignored.