The invoice was for a run of injection-moulded housings, the terms on it read Net 30, and the supplier expected their money thirty days after they cut it. Your accounts-payable system paid on day forty-four, and it did nothing wrong. The payment terms record in your ERP said Net 30 too. What it did not say was thirty days from when. The clock in your system started at goods receipt, and the parts had sat on a truck and then a dock for two weeks before anyone booked them in. Net 30 from receipt is Net 44 from the invoice, the supplier read it as late, and on day thirty-one they put your account on credit hold, the morning before the line was due to run out of the exact housing that invoice was for.
Payment terms are the master data domain everyone assumes the ERP handles, because the ERP has a field for them. It does. The field holds a code. The code points at a definition, and the definition is where the money and the goodwill actually live. It is set up once per supplier by whoever onboarded them, copied from a similar vendor when nobody was sure, and never looked at again.
A payment term is a formula, not a number
Net 30 looks like a single fact and behaves like a small calculation. It has at least three parts, and only one of them is obvious. There is the net period, the thirty days everyone sees. There is the baseline date, the event the thirty days count from, which never appears on the invoice and lives in a setting most people have never opened. And there is the discount tier, the offer to pay early for a small cut, which may or may not be present and runs on its own separate clock.
So a payment term is baseline date, plus net days, plus an optional discount, set per supplier. Store only the middle number and you have kept the least important third of it. This is the same trap as a unit of measure with no conversion factor or a currency rate with no effective date: the value you can see is fine, and the value that does the work was never captured.
The baseline date is the variable nobody stores
Net 30 counts thirty days from something, and the something has at least four candidates: the invoice date, the date you received the invoice, the date you received the goods, and the end of the invoice month. Each one is a legitimate baseline, in real use somewhere, and each one lands the due date on a different day. Same code, same thirty, four answers.
Here is the part that makes it dangerous. Nobody negotiates the baseline. Two parties haggle over the number of days and shake on Net 30, and the baseline is left to whatever each side's system happens to default to. The supplier's system counts from the invoice, because that is the moment they care about. Yours counts from goods receipt, because that is the moment your obligation feels real. Both are being reasonable, and the fourteen days between them is the invoice in transit, which nobody put a number on because nobody thought there was a number to put.
Where payment terms break
None of these is a typo. In every one, the code was valid and the people did their jobs. The damage lives in the definition behind the code and the parts of it that never got stored.
The discount with no window
A supplier offers 2/10 net 30: two percent off if you pay within ten days, full amount at thirty. The terms record captures the two percent and forgets the ten days, because there is one field for the discount and none for its deadline. Now AP deducts the two percent on every payment, including the ones that go out on day twenty-eight, and for a year nobody notices. Then the supplier reconciles, finds the discounts you were never entitled to, and issues a debit note for all of them at once.
Two codes for one term
N30, NET30, and 30 all exist in the terms list, seeded over the years by three people who each could not find the one already there. Half your suppliers point at one, half at another, and a cash-flow forecast that groups by terms code splits a single population into three lines that each look too small to matter. A downstream treasury tool maps only one of the codes, so the payments under the others land in its unknown-terms bucket and drop out of the projection entirely.
The baseline nobody agreed on
Your contract says Net 30 and means from the invoice date. Your system computes Net 30 from goods receipt, because that is the box it was set up in, and receipt lags the invoice by however long the goods spend in transit and in the receiving queue. Neither number is a bug. They are two honest readings of the same two words, and the distance between them is exactly the amount by which you are, structurally, paying every one of those suppliers late.
End-of-month terms that drift
Net 30 end-of-month means thirty days from the last day of the invoice month, so an invoice dated the 2nd gets nearly sixty days and one dated the 30th gets thirty-two. If the end-of-month flag is not stored as part of the term, and the system just counts thirty days from the invoice date, both come out at thirty. The first invoice is paid almost a month before the supplier expects it, and the cash forecast for that month is off by the size of the swing.
The terms that outlived the deal
Procurement renegotiated this supplier from Net 30 to Net 60 eighteen months ago to ease cash flow. The terms in the vendor master still say Net 30, because the change happened in an email and a contract, not in the system, and nobody owned the step that carried it across. So you keep paying a month early, hand back the interest-free month you already won at the table, and report a DPO your own treasury targets say you beat.
They share a symptom. The wrong terms never throw an error, they just move a date, and a payment on the wrong date still clears the bank. So the failure surfaces as a supplier complaint, a debit note, or a cash forecast that misses, weeks after the record that caused it was last touched. It is the same way a report comes out confidently wrong while every job in the pipeline reports success.
Rules that keep terms honest
Store the whole formula, not the label. The baseline date, the net days, and the discount tier each need their own governed field, so that Net 30 cannot mean four things and a discount rate cannot exist without the window that qualifies it. A percentage with no days beside it should not be a valid record.
Keep one authorized list of terms codes, with an owner and an approval step in front of new ones, the same as any other reference list. That is what stops N30, NET30, and 30 from breeding until a report on terms is meaningless. Tie the terms to the supplier record under the same governance, so that when procurement renegotiates, the change lands as an approved, effective-dated changeset rather than an email nobody carried across.
Then reconcile the terms against what you actually pay. Days-payable-outstanding by supplier that drifts from the stated terms is the cheapest early warning you have: it catches the baseline you set wrong and the discount you have been taking without earning, before the debit note does. And treat a terms change like the sensitive edit it is. Shortening a supplier to prepayment, or slipping in a discount, moves real money on the next run, which makes it the same soft target as a bank-account change, and it deserves the same approval and the same audit trail.
If you are coming off MDS
Microsoft MDS could hold a Payment Terms entity without much trouble: a code, a description, a net-days attribute, a tidy lookup. What it had no natural place for was the rest of the formula and the governance around it, the baseline date as a controlled value, the discount tier with its own window, the link from the term to the supplier, and an approval in front of a renegotiation. So in the MDS estates I have seen, the terms code sat in the model as a neat reference entity while the definition that actually decided the due date lived in the ERP's vendor master, un-owned and un-audited, edited by whoever had the screen open.
If you are migrating off MDS, that split is the thing worth closing on the way across. The whole definition belongs under one governed roof, tied to the supplier, effective-dated and approved. The migration is also the moment to find out how many of your suppliers are running on terms nobody has revisited since the day they were onboarded, and how many of your Net 30s quietly mean Net 44. The count is rarely zero, and you would rather learn it now than from a credit hold on the morning of a delivery you could not afford to miss.
Common questions
What is payment terms master data?
The governed definition behind a code like Net 30, not just the code. A payment term is a small formula: the baseline date the clock counts from, the net period in days, and an optional early-payment discount with its own deadline, all set per supplier. The code list is reference data. The definition behind each code decides when money moves, and it is the part almost nobody governs.
Why does the baseline date matter so much?
Because Net 30 does not say thirty days from when, and the answer moves the due date by weeks. Thirty days from the invoice and thirty days from goods receipt differ by however long the goods sit in transit and in receiving. Same number, two honest due dates. Whichever you did not intend, you are paying late and risking a credit hold, or paying early and giving away a month of your own cash.
Should payment terms live in the ERP or the MDM system?
The ERP executes the payment, so it needs the terms, but that does not make it the owner. Terms are usually set once per supplier at onboarding and never reviewed, with no owner and no approval. MDM fixes that: one code list, the full definition as governed attributes, tied to the supplier, with renegotiations applied as approved, effective-dated changes the ERP reads. MDM owns the truth; the ERP consumes it.
How do 2/10 net 30 discount terms get mishandled?
They carry two clocks: the net period and a separate discount window. The usual failure is storing the discount percentage without its deadline, because there is a field for the rate and none for the days. AP then takes the discount on every payment regardless of timing, and the supplier reconciles months later and claws it all back in one debit note. A discount rate with no window beside it quietly creates money you will owe back.
Make Net 30 mean one thing
Primentra governs payment terms as first-class master data on your own SQL Server: the baseline date, net days, and discount tier as typed attributes, one authorized code list, changeset approvals in front of a renegotiation, and an audit trail of who changed which supplier's terms and when. It deploys in a day and costs €7,500 per year flat. The 60-day trial is long enough to bring a real terms table under control.