Every Buyer Wants a Different Invoice: Managing Per-Customer Delivery Templates at Scale
There is a particular kind of institutional knowledge that never makes it into a process document. Ask an AR team who handles the invoices for their largest customer and you will get a name, not a procedure. Ask what that person does differently, and you will get a list: this buyer needs the cost centre in the reference field, that one rejects anything with more than twenty line items, the other requires the delivery order attached as a separate PDF with a specific filename.
None of it is written down. All of it is load-bearing. And it is the reason rejection rates jump in a way nobody can explain whenever that person takes two weeks off.
What Is a Per-Customer Delivery Template?
A per-customer delivery template is a stored, explicit definition of one buyer’s invoice requirements, applied automatically when the invoice is submitted. Not a document someone is supposed to read first — a definition the submission process enforces.
The distinction matters because almost every AR team already has templates in the informal sense. They exist as a spreadsheet tab, a shared inbox folder of past examples, a note in the CRM, or most commonly as a person’s memory. Those are not templates; they are reminders, and reminders fail under pressure.
A real template covers six categories of rule.
| Rule category | Examples | Typical failure when missing |
|---|---|---|
| Identifiers | PO number, cost centre, project or WBS code, contract reference, requisitioner name | Hard rejection — the invoice cannot be matched |
| Mandatory fields | Tax registration, delivery date, payment terms, buyer contact | Hard rejection or silent parking |
| Formatting constraints | Line-item granularity, description wording, currency and rounding, maximum line count | Rejection or a query that stalls approval |
| Attachments | Delivery order, timesheet, entry sheet, test certificate, naming convention | Approver stalls, invoice ages quietly |
| Channel and destination | Which portal, which sub-entity, email fallback, Peppol endpoint | Invoice delivered somewhere nobody is watching |
| Timing | Submission windows, month-end cut-offs, period alignment | Invoice lands in the wrong accounting period |
Why Does Every Buyer Want Something Different?
It is tempting to treat this as buyer unreasonableness. It mostly is not. Each buyer’s requirements are downstream of decisions they made for their own reasons.
Their ERP configuration determines which fields are mandatory and how tightly a line item must match a PO line. A buyer running a heavily customised instance will have requirements that look arbitrary from outside and are structural from inside.
Their approval workflow determines which attachments an approver needs to sign off without asking a question. A buyer whose approvers are site managers rather than finance staff will want operational evidence, not just a compliant document.
Their tax and statutory position determines registration numbers, tax breakdowns and retention requirements, which vary by jurisdiction and entity.
Their procurement policy determines reference requirements — cost centre, project code, contract number — because that is how they allocate spend internally.
None of these were designed with suppliers in mind, and none of them converge, because there is nothing for them to converge on. Standards help at the document layer: the Peppol BIS Billing specification and the European eInvoicing framework define what a structurally valid invoice looks like, and that genuinely removes formatting variation. They do not and cannot define which cost centre a given buyer wants in which field. Business-rule variation survives standardisation entirely.
This is the inverse of a problem we have written about from the AP side. In format-agnostic invoice processing, the buyer chooses to accept whatever suppliers send rather than forcing template compliance. That is the right call when you are the one receiving. When you are the supplier submitting into someone else’s portal, you have no such choice — you comply with their rules or you do not get paid, which is the dynamic behind rigid vendor portals forcing suppliers to reshape their billing practices.
Why Is Tribal Knowledge the Real Problem?
The requirements themselves are an inconvenience. The way they are stored is the actual risk.
It is a single point of failure. When one person holds the rules for forty accounts, their absence is a billing outage. This shows up in the numbers as a rejection spike with no obvious cause, usually attributed to a bad month.
It does not survive growth. Knowledge held in memory scales linearly with headcount at best. Adding customers faster than you add people means the per-person rule load rises until accuracy degrades — the structural problem behind scaling portal management past 200 relationships.
It cannot be audited or improved. You cannot review a rule set that exists only in conversation. You cannot tell which rules are real, which are superstition left over from one rejection in 2023, and which have quietly changed.
It makes onboarding slow. A new AR hire takes months to reach competence not because the work is hard but because the rules are undiscoverable. They learn by being rejected.
It hides commercial problems. When a customer’s rejection rate is high, you cannot tell whether your template is wrong or their process is unreasonable, which means you never have the commercial conversation.
How Do You Discover What a Buyer Actually Requires?
The instinct is to ask the buyer or read their supplier guide. Both are weak sources. Published guides are frequently out of date, written for a previous ERP version, or describe the ideal rather than what the portal enforces. Asking a buyer contact gets you their understanding, which may not match their system’s behaviour.
The reliable source is your own rejection history.
Export twelve months of rejected and queried invoices and group them by customer. Every rejection is a documented instance of a rule you broke, with the buyer’s own description of why. This is a far more accurate specification than anything they publish, because it reflects what is actually enforced.
Then interview the person who handles each major account, and ask one specific question: what do you do differently for this customer that you would have to explain to someone replacing you? That phrasing surfaces the undocumented adjustments. Asking “what are the requirements?” gets you the published list; asking what they would have to explain gets you the real one.
For each rule, record four things: the rule itself, where it came from, what happens when it is broken, and when it was last confirmed. The third field is the useful one — a rule with no known consequence is often folklore, and can be retired rather than maintained forever. The approach parallels the triage discipline in building exception ownership across distributed account teams, where the point is to make causes visible rather than just clear the queue.
How Many Templates Do You Actually Need?
Fewer than your customer count, which is the encouraging part.
Requirements cluster by portal platform, because the platform constrains what a buyer can demand. Most Coupa buyers want broadly similar things; so do most Ariba buyers. The practical structure is a base template per portal platform, plus genuine overrides only where a customer is unusually strict or unusually high-volume.
This maps onto the sequencing logic in applying the 80/20 rule to portal automation: a small number of portals carry most of the volume, so a small number of templates covers most of the risk. The long tail of one-invoice-a-year customers does not need a bespoke template; it needs a sane default and a human glance, which is the same conclusion we reach for the long tail of custom invoice destinations.
| Tier | Population | Template approach | Review cadence |
|---|---|---|---|
| High-volume, strict buyers | Usually 5-15 accounts | Full dedicated template with explicit overrides | Quarterly |
| Standard portal buyers | The bulk of accounts | Base template per portal platform | Semi-annually, or on rejection |
| Long tail | Many accounts, low volume each | Sane default plus human review | On rejection only |
| Discovery source | Accuracy | Effort | What it misses |
|---|---|---|---|
| Buyer’s published supplier guide | Low to moderate | Low | Rules the portal enforces but the guide never documented |
| Asking the buyer’s AP contact | Moderate | Low | Gaps between their understanding and their system’s behaviour |
| Your own rejection history | High | Moderate | Rules you have not yet broken |
| Interviewing your account handler | High | Low | Rules they apply unconsciously and forget to mention |
Why Must Templates Be Enforced Rather Than Advisory?
This is the step most teams skip, and it decides whether the whole exercise was worth doing.
A template written as documentation is consulted when there is time. At month-end there is no time. The invoice goes out the way the person remembers, the documentation drifts from practice, and within two quarters you have a document nobody trusts and the original tribal knowledge back in place — now with the added cost of having written something that is wrong.
A template encoded as a pre-submission validation behaves differently. The check runs on every invoice, every time, regardless of workload. A non-compliant invoice cannot be submitted, so the rule cannot silently decay. This is the same preventive principle as real-time validation with instant error feedback: catching the problem before submission converts a multi-week buyer rejection cycle into a few seconds of internal correction.
Enforcement also makes drift detectable. When a validation starts failing on invoices that used to pass, something changed on the buyer’s side — and you now have a signal instead of a mystery. Buyer requirements shift after ERP upgrades, policy refreshes, tax changes and contact changes, and buyers almost never announce any of it.
Governance bodies frame this as ordinary internal control: the COSO internal control framework treats a control that depends on individual memory as weak by definition, and professional guidance from IFAC and the Association for Financial Professionals points the same way. A billing rule set is a control environment, whether or not anyone has called it that.
What Should You Measure?
First-pass acceptance rate by customer is the primary metric — the share of invoices accepted without rejection or query on first submission. It isolates template quality from downstream approval delay. A customer whose rate stays stubbornly low after template work almost always has a data or commercial problem rather than a formatting one.
Rejection rate by rule category, using the six categories above, tells you where to invest. Identifier failures suggest a data mapping problem upstream; attachment failures suggest a document retrieval problem.
Template staleness — the age of the last confirmation per template — predicts future failures better than current rejection rates do.
Rejection concentration by individual is uncomfortable but informative. If rejections cluster around whoever is covering for someone, your rules are still tribal regardless of what you have documented.
How Peakflo Helps
Peakflo’s invoice delivery to AP portal automation stores each buyer’s layout, references and mandatory fields as a per-customer delivery template, applied automatically at the moment of submission rather than left as a note for an analyst to remember. The AI browser agent enters the invoice into the buyer’s portal using that customer’s own field mapping, applies their reference requirements, and attaches the documents their approver expects — so compliance happens on the first attempt instead of after a rejection.
Variances in quantity, price and tax are flagged before submission, which means a template breach surfaces as an internal exception resolved in seconds rather than a buyer rejection discovered weeks later. Because the agent works the portal interface directly, templates can be maintained for Coupa, SAP Ariba, Tungsten, Jaggaer, Basware and in-house portals alike, with no API and nothing required from your customer’s IT team — and a new customer’s template can be stood up without waiting in an integration queue. To see how your own buyer rule set would be encoded, request a demo.
Our Verdict
Per-customer invoice rules are not a formatting nuisance. They are an undocumented asset that most suppliers depend on and almost none manage deliberately.
Our position: harvest the rules from your rejection history rather than from buyer documentation, because the rejection history is the only honest specification of what is actually enforced. Then encode them as validations rather than notes, because advisory templates do not survive month-end. The teams that do this stop discovering requirements through rejection and start discovering changes through a failing check — a much cheaper way to learn the same information.
The structural insight is that this knowledge is a control environment, not a filing problem. Rules held in individual memory are a weak control by any standard framework’s definition, and the weakness shows up as DSO variance that nobody can attribute. Treat the template set as versioned, owned and reviewed, and the variance becomes explicable and then fixable.
Conclusion
Your buyers will not standardise. Their requirements come from their own ERP configurations, approval chains and tax positions, and there is no shared standard for those to converge on — so the variation is permanent and your handling of it is the only variable you control.
Start with the rejection export, because it is the fastest route to an accurate rule set. Ask each account handler what they would have to explain to a replacement. Encode what you find as pre-submission checks, version it, and watch first-pass acceptance by customer. The goal is not fewer rules; it is rules that live somewhere other than in one person’s head.
Frequently Asked Questions
What is a per-customer invoice delivery template?
A stored definition of one buyer’s invoice requirements: their mandatory references, required fields, line-item granularity, attachments, naming conventions and submission channel. It is applied automatically at submission so the invoice complies on the first attempt.
Why does every buyer want a different invoice format?
Because each buyer’s requirements come from their own ERP configuration, approval workflow, tax position and procurement policy. Those were designed independently, so there is no shared standard for them to converge on.
What is the risk of keeping buyer rules in people’s heads?
Rejection rates spike whenever the person who knows a customer is absent or leaves. Undocumented billing knowledge behaves like a single point of failure, and the cost appears as unexplained DSO variation rather than as a staffing problem.
What belongs in a delivery template?
Identifiers such as PO and cost centre, mandatory fields, line-item granularity and description rules, tax treatment, required attachments, file naming and format, submission channel and portal, plus timing windows and cut-offs.
How do you discover a buyer’s real invoice requirements?
From your own rejection history rather than their documentation. Twelve months of rejected and queried invoices grouped by customer reveals the rules that are actually enforced, which often differ from what the published supplier guide says.
Do e-invoicing standards remove the need for templates?
They reduce formatting variation but not business-rule variation. A standard defines the structure of a compliant invoice; it does not dictate which cost centre a particular buyer requires or which attachments their approver expects.
How many templates does a supplier typically need?
Fewer than the customer count. Requirements cluster by portal platform and buyer size, so most suppliers find a base template per portal plus genuine overrides for high-volume or unusually strict customers.
How often do buyer invoice requirements change?
Material changes are common after a buyer ERP upgrade, a procurement policy refresh, a tax change or a change of contact. Because buyers rarely announce them, the first signal is usually an unexpected rejection.
Should templates be enforced or advisory?
Enforced. A template that exists as a document someone is supposed to consult will be bypassed under month-end pressure. Encoded as a pre-submission validation, a non-compliant invoice simply cannot be submitted.
How do you keep templates from going stale?
Version and date-stamp every template, record who changed what and why, re-confirm high-volume customers quarterly, and treat any rejection as a trigger to review the relevant template immediately.
Can delivery templates be applied automatically at submission?
Yes. When submission runs through an AI browser agent, the template is applied as the invoice is entered into the buyer’s portal, including their field mapping, references and attachments, with validation before anything is sent.
What metric shows whether templates are working?
First-pass acceptance rate by customer. It isolates template quality from downstream approval delays, and a customer whose rate stays low after template work usually has a commercial or data problem rather than a formatting one.