Credit Memos, Prepayments and Recurring Contracts

Not everything arriving in accounts payable is an ordinary invoice for goods received. Three other kinds turn up regularly, and each needs to be checked against something different.

The unifying idea is worth stating first: every document needs an authority — something that independently says this spend is legitimate and this is how much. For an ordinary invoice that is the purchase order plus the posted receipt. For these three it is something else.

Credit memos

A credit memo is the vendor giving money back — for returned goods, an overcharge, a damaged delivery, a negotiated settlement.

Its authority is the original posted invoice. The check has two parts:

Can it be tied to a posted document? A credit memo that references no identifiable original is unverifiable. You have no way to know whether it relates to something you paid, or to nothing at all.

Does it exceed the original? A credit larger than the invoice it credits is either an error or something more interesting. This should be checked per line as well as in total — a credit that is correct overall but over-credits one line and under-credits another is still wrong, and the line detail is where returns disputes actually happen.

Both should stop the document rather than pass. It is tempting to wave credits through because money moving in your favour feels safe. It is not: an unmatched credit memo distorts your payables and can mask a real dispute, and a credit posted against the wrong original leaves both accounts wrong.

Prepayments

A prepayment invoice asks for money before anything arrives. Common for custom manufacturing, large capital items, and new vendors offering no credit terms.

There is no receipt, and there never will be at this stage. That is not a failure; it is what a prepayment is.

Its authority is a purchase order carrying authorized prepayment terms. Business Central supports prepayment percentages and amounts on a purchase order, and somebody had to set them when the order was raised.

So the check is: does an order exist for this vendor with prepayment terms authorising this? If not, the honest answer is that nobody agreed to pay in advance, and that decision needs a person — not a tolerance.

The reason this matters more than it seems: a prepayment is the one document type where you are paying with no evidence of delivery at all. Every other control in accounts payable rests on something having arrived. The advance authorisation on the order is the only thing standing in for it.

Recurring contracts

Rent. A service retainer. Software subscriptions. Cleaning. Maintenance.

These will never have a purchase order and will never have a receipt, and raising a PO every month for the same rent is a policy that gets abandoned within a quarter.

But they are not unpredictable. Somebody signed something. That is the authority — a contract record carrying a period and a cap.

With one in place, a recurring invoice becomes checkable:

  • Is there an active contract for this vendor, covering this date?
  • Is the amount within the period cap?

That is a real check. It catches the month the amount changes without notice, the invoice that arrives twice, the invoice that arrives after the contract ended, and the annual increase nobody was told about.

Setting up contract records is the single highest-value thing most organisations can do about their non-PO spend, because it converts a large, regular category from “somebody codes it by hand and hopes” into something with an authority behind it.

The kind that should never be guessed

The fourth case is a document whose kind could not be determined at all — a statement, a dunning letter, a delivery note, a remittance advice, or something the reader genuinely could not classify.

The correct default is Unknown, and Unknown should route to a person.

The tempting default is “ordinary invoice”, because most documents are. That is the wrong choice, and the reason is specific: an unclassified document processed as an ordinary invoice will be reconciled against orders and receipts it has nothing to do with. It will either fail confusingly, or — worse — happen to match something and produce a document nobody intended.

A statement listing five invoices you have already received, processed as if it were an invoice, is a duplicate payment waiting for a signature.

A reader that is unsure should say so. “Unknown” is a useful answer; a confident wrong classification is not.

What this means in practice

Four questions worth asking of any invoice-handling process:

  1. What is this document’s authority? If you cannot name it, nothing is checking the amount.
  2. What happens to a credit memo that references nothing? Stopping it is the right answer.
  3. What happens to a prepayment against an order with no prepayment terms? Same.
  4. What happens to a document that is not an invoice at all? If the answer is “it becomes an invoice”, that is a problem.

Everything above is about the same underlying discipline as three-way matching: find the independent record that says what this should be, and check the claim against it. These three kinds simply have different records.

Questions about DocumentQ?

Support: support@dynamicspro.ca · 416-843-6575