Skip to content

The reasons customers give for paying late read like a design brief for order-to-cash.

Thousands of receivables managers were asked the same question this year across four regions. After customer cash flow, every answer they gave describes something a supplier decides before the invoice is ever sent.

The thesis: the second, third and fourth answers are the buildable ones.

Every finance team has a view on why customers pay late, and the view is usually some version of because they can. It is a satisfying explanation and it produces exactly one action, which is to chase harder. This year there is better material to work with. The 2026 Atradius Payment Practices Barometer put the question directly to people whose job is managing receivables, across four regional editions and roughly six and a half thousand interviews, and published what came back.

The first answer is the one everybody expects. Customer cash flow leads in every region, from 46% of respondents in Asia to 61% in Central and Eastern Europe. That is real, and at invoice time it is genuinely outside a supplier’s control. What makes the survey worth reading twice is the rest of the list. Internal approval delays. A complex payment process. Goods or services not as agreed. Those are not descriptions of unwillingness. They are descriptions of friction between an invoice and the person who has to approve it, and every one of them is settled by choices a supplier makes long before a reminder is sent.

The Secret CFO@SecretCFO2 May 2026Post on X

Working capital is the most underestimated force in business.

A useful reminder of the stakes underneath a collections conversation. Working capital is where growth is financed or where it quietly runs out, and receivables is the half of it that a finance team can influence customer by customer. View the original post on X by @SecretCFO on 2 May 2026

There is a second piece of context that makes this more interesting rather than less. On 16 July 2026 Allianz Trade published its annual cash conversion cycle report and found that global payment terms rose slightly to 56.5 days in 2025, up 0.3 days, stable at that level since 2022 and still three days below the pre-pandemic norm. The pressure on the cash conversion cycle came from inventory: the global figure rose half a day to 67 days of turnover, with days inventory outstanding at 53 days, and the firm’s lead analyst for insolvency research said that days inventory outstanding now explains almost 80% of the cash conversion cycle level.

Put those two findings side by side and the picture sharpens. There is no rising macro tide in receivables to blame or to wait out. Yet inside the same economies, 23% of Western European respondents report no overdue B2B invoices at all while 10% report that more than three in five of their invoices go past due. That spread is not weather. It is made of decisions, and the survey is unusually specific about which decisions they are.

What the 2026 surveys actually asked, and what came back.

The Payment Practices Barometer is an annual survey run by the trade credit insurer Atradius. Respondents are screened for the role, so these are people responsible for accounts receivable management rather than a general business panel. The 2026 Western Europe edition ran between the end of the first quarter and the beginning of the second quarter of 2026, with 2,945 interviews across eleven markets, quotas across four company size bands, and results weighted to reflect the economic weight of each sector, size class and market. The reasons question is multiple response, so the percentages are the share of respondents naming each cause rather than a split of a hundred.

One methodology note the reports make themselves is worth carrying: for this edition the panel was updated to better reflect market structure, and Atradius states that comparisons with previous reports are not possible, with annual variation captured only through respondent feedback. So this is a good snapshot and a poor trend line. Read it as a description of the current shape of the problem, which is what it is useful for anyway.

RegionInterviewsNamed firstNamed secondNamed thirdNamed fourthReport no late invoices at all
Western Europe2,945Customer cash flow issues, 53%Internal approval delays, 23%Banking delays, 23%Complex payment process, 15%23%
United Kingdom210Customer cash flow issues, 51%Banking delays, 26%Internal approval delays, 23%Complex payment process, 17%34%
Central and Eastern Europe1,684Customer cash flow issues, 61%Banking delays, 23%Internal approval delays, 15%Complex payment process, 14%17%
Asia2,145Customer cash flow issues, 46%Goods or services not as agreed, 26%Banking delays, 26%Complex payment process, 25%18%

The consistency across four independent regional samples is the finding. Customer cash flow first everywhere. Banking delays present everywhere at 23% to 26%. Approval friction and payment mechanics present everywhere, together named by a substantial minority of respondents in every region. Asia is the interesting variation: goods or services not as agreed comes in second at 26%, which is a dispute cause rather than a delay cause, and it does not appear in the top four for any of the European regions.

The rest of the Western Europe numbers give useful shape. Roughly one quarter of invoices are paid after the due date, and once overdue, 71% of past due invoices are settled within thirty days, 17% within thirty-one to sixty days, 7% within sixty-one to ninety, and 5% beyond ninety. Credit losses average 1.6% of B2B invoiced turnover. Trade credit now accounts for about 52% of B2B sales across the region, ranging from 22% in France to 73% in the Netherlands. In other words the exposure is large, the tail is short, and the volume of late invoices matters more than how long each one takes to recover, which the report itself states plainly.

Company size changes the picture in a way worth noticing. In the Western Europe appendix, 68% of micro businesses set payment terms under thirty days, falling to 37% for small firms, 27% for mid-sized firms and 24% for large ones. Days sales outstanding follows the same slope. Larger organisations are not worse at collecting. They sell to buyers with longer approval chains, and the approval chain is precisely where the second and fourth causes live.

Reading each named cause as a piece of order-to-cash design.

Here is the reframe the survey invites. Take each named cause, ask where in your own chain that outcome is actually decided, and the answer is almost always a field, a rule, or a gate that already exists in the ERP and is currently set by habit.

Named causeWhat it meansWhere it is decided in your chainWhat to change
Customer cash flow issuesThe buyer does not have the money on the due date. Named first in all four regions, from 46% of respondents in Asia to 61% in Central and Eastern Europe.The credit decision, made before the order was accepted. Credit limit, terms, and the release rule on the customer master.This is the cause a supplier cannot talk its way out of after the fact, which is exactly why it belongs upstream. A credit limit that is reviewed on a schedule, a terms field that cannot be overridden silently, and an order release rule that fires on exposure rather than on a person remembering.
Internal approval delaysThe buyer has the money and the invoice is sitting in someone’s queue. Named by 23% of respondents in Western Europe and the United Kingdom, and 15% in Central and Eastern Europe.The invoice header and the delivery of it. Purchase order reference, buyer contact, cost centre or project code, legal entity, and the channel the invoice arrives on.An invoice that lands in the buyer’s workflow already matched to their purchase order starts its approval clock immediately. One that arrives without a reference, or at a generic mailbox, waits for a human to work out where it belongs before the clock starts at all.
Complex payment processThe buyer is trying to pay and the mechanics are getting in the way. Named by 15% of respondents in Western Europe, 17% in the United Kingdom and 25% in Asia, the highest of the four regions.The remittance instructions on the invoice, the payment methods offered, and whether the reference the buyer can quote is one the supplier can match on receipt.The fix is usually unglamorous and cheap. One set of bank details per selling entity and currency, a payment reference the buyer’s system can carry through unchanged, and a stated method for the customers who cannot use the default.
Goods or services not as agreedThe buyer is disputing rather than delaying. Named by 26% of respondents in Asia, where it ranks second, and absent from the top four in the three European regions.The order, the delivery, and the price the invoice was built from. Contract price versus price list, quantity delivered versus quantity billed, and the service record behind a milestone.Every dispute of this kind is a data mismatch that existed before the invoice was raised. The useful question is not who is right, it is which of the three records disagreed, because that tells you which control to add.
Banking delaysValue dates, cut-offs, cross-border routing and intermediary handling. Named by 23% to 26% of respondents in every region surveyed.Mostly outside the supplier’s system, and partly inside it through method, currency and the value date assumption behind the due date.The honest answer is that this one is largely someone else’s rail. The part a supplier controls is whether the due date on the invoice reflects how the money actually travels, so that a payment sent on time does not read as late in the ageing.

The pattern in that table is the whole argument. Four of the five rows resolve to something held on the supplier’s side: a limit, a terms field, a reference format, a price list, a delivery record, a set of bank details. Only banking delays genuinely belongs to somebody else, and even there the supplier owns whether the due date convention reflects how the money travels.

Where each named reason for late payment is actually decidedA left to right order-to-cash path with five stages: the credit decision on the customer master, the order, the delivery, the invoice, and the customer approval and payment that follows. The four reasons respondents named for late payment are attached to the stage where each one is decided. Customer cash flow attaches to the credit decision at the start, because the only lever a supplier holds over it is the limit, the terms and the order release rule set before anything ships. Goods or services not as agreed attaches jointly to the order and the delivery, because a price or quantity dispute is a disagreement between the order line, the delivery record and the invoice line that already existed before billing. Internal approval delays attach to the invoice, because whether an invoice enters the buyer approval queue immediately depends on the purchase order reference, the buyer contact, the entity and the channel the supplier put on it. Complex payment process attaches to the invoice as well, through the remittance instructions, the accepted methods and the payment reference. Only banking delays sit past the last stage, outside the supplier boundary, shown as a dotted box. A bracket underneath marks the first four stages as the supplier design boundary, making the point of the drawing: three of the four named causes are decided on the supplier side of that boundary, before the invoice is ever sent.WHERE EACH NAMED CAUSE IS ACTUALLY DECIDEDCredit decisionlimit, terms, releaseOrderprice, quantity, refDeliverywhat actually shippedInvoicefields, channel, remitBuyer approvesand paysCUSTOMER CASH FLOW46% to 61% ofrespondents. Your onlylever is set here.NOT AS AGREED26% in Asia. A mismatchbetween order, deliveryand invoice.APPROVAL AND PAYMENT FRICTION15% to 25% each. Decided bythe fields, the channel and theremittance you put on it.BANKING DELAYS23% to 26%. Someoneelse’s rail. Set the duedate to match it.EVERYTHING LEFT OF THIS LINE IS YOUR DESIGNThree of the four named causes are decided before the invoice is sent. Only one of them is decided by the buyer’s bank balance,and even that one has a lever, set at the credit decision rather than at the reminder.
The four named causes and their percentage ranges are the top four answers reported in the 2026 Atradius Payment Practices Barometer regional editions for Western Europe, the United Kingdom, Central and Eastern Europe, and Asia. Attaching each cause to the stage of the order-to-cash chain where it is decided, and drawing the supplier design boundary, is our framing rather than the survey’s.
Merlin@merlinkafka27 July 2026Post on X

Order-to-cash is one of the clearest places to start: it is high-volume, manual work with a direct impact on cash.

A product launch post rather than research, and quoted here for the framing rather than the product. It is a fair description of why this part of finance stays manual: the work is high volume, it sits across several systems, and it lands directly on cash. View the original post on X by @merlinkafka on 27 July 2026

The reason code, and why the ageing should sort by cause.

Most order-to-cash functions already collect this information and then throw it away. A collector calls, learns exactly why an invoice has not been paid, and records it as a note. The note is genuinely useful to the next person who calls that customer, and completely useless for answering the only question that changes anything: across the whole ledger, which cause is costing us the most days?

The fix is small and structural. Make the reason a mandatory coded field on the dispute or short payment record, keep the taxonomy short enough that a collector will use it accurately, and give every code a named owner who can act on it. A code with no owner should not be in the list, because it produces a number nobody is accountable for. Here is a worked example of the shape, sized to the causes the surveys actually name.

An example dispute reason taxonomy, sized to the named causes

{
  "taxonomy_id": "ar_dispute_reason_v1",
  "purpose": "Classify every short payment, dispute and overdue document by cause, so ageing can be sorted by what to fix rather than only by how old it is.",
  "codes": [
    {
      "code": "LIQ",
      "label": "Customer liquidity",
      "family": "outside our design",
      "evidence_required": "A dated collector contact record naming a payment plan, a partial receipt, or a credit review trigger.",
      "owned_by": "credit",
      "feeds": "credit limit review, provisioning, terms renegotiation"
    },
    {
      "code": "APR",
      "label": "Awaiting customer internal approval",
      "family": "invoice presentation",
      "evidence_required": "The customer's own status, plus which required field was missing or unmatched at their end.",
      "owned_by": "billing",
      "feeds": "per customer invoice field requirements, first pass approval rate"
    },
    {
      "code": "REF",
      "label": "Missing or wrong purchase order or contract reference",
      "family": "invoice presentation",
      "evidence_required": "The reference we sent and the reference the customer expected, both recorded.",
      "owned_by": "order management",
      "feeds": "order entry validation, customer master reference rules"
    },
    {
      "code": "PRC",
      "label": "Price or quantity disputed against the order",
      "family": "order and delivery data",
      "evidence_required": "Order line, delivery record and invoice line side by side, with the field that differs identified.",
      "owned_by": "revenue operations",
      "feeds": "price list governance, contract price maintenance, billing validation"
    },
    {
      "code": "DLV",
      "label": "Delivery or service performance disputed",
      "family": "order and delivery data",
      "evidence_required": "Proof of delivery or the service record behind the milestone that was billed.",
      "owned_by": "operations",
      "feeds": "milestone billing rules, proof of delivery capture"
    },
    {
      "code": "PAY",
      "label": "Payment mechanics",
      "family": "remittance design",
      "evidence_required": "The method attempted, the reference quoted, and where it failed to match.",
      "owned_by": "cash application",
      "feeds": "remittance instructions, accepted methods, matching rules"
    },
    {
      "code": "BNK",
      "label": "Banking or value date delay",
      "family": "outside our design",
      "evidence_required": "Payment initiation date from the customer against value date received.",
      "owned_by": "treasury",
      "feeds": "due date convention by method and corridor"
    }
  ],
  "rules": {
    "single_code_required": true,
    "free_text_allowed_as": "supplement, never as substitute",
    "unclassified_target": "under 5% of overdue value",
    "review_cadence": "monthly, with the top code by value taken to the order-to-cash owner"
  }
}

Once that field exists, the aged trial balance stops being one queue and becomes four. The liquidity queue goes to credit, with a limit review and a provisioning consequence. The approval and reference queue goes to billing, and each item in it is evidence for a field rule that should have been applied at release. The price and delivery queue goes to revenue operations, and it points at a specific price list entry or a specific proof of delivery gap. The payment mechanics queue goes to cash application, and it is usually the shortest and the cheapest to clear.

The unclassified rate is the number to watch while this beds in. If more than a small fraction of overdue value carries no code, the taxonomy is too long, the field is not mandatory at the right moment, or nobody has explained why it matters. All three are fixable in a month, and none of them require a system change.

Two measures worth building toward, and two worth keeping honest.

Days sales outstanding is a fine headline and a poor instruction. It moves for reasons that have nothing to do with performance, including sales mix, seasonality, and a single large invoice landing on the wrong side of a period end. These four measures are narrower, and each one points at an owner.

MeasureDefinitionWhat it is built fromWhy it earns its place
First pass approval rateThe share of invoices that clear the customer’s approval without a query, a resend, a credit note, or a correction.Every invoice line that gets touched twice. Count a resend as a failure even when the customer eventually pays on time, because the second send is the work you are trying to remove.This is the measure that moves the internal approval delay cause. It is also the one most order-to-cash teams have never computed, because a resend usually leaves no trace beyond an email.
Cause split days sales outstandingOverdue days attributed to disputes and process friction, held separately from overdue days attributed to customer liquidity.The coded reason on each dispute or short payment record, joined to the days that document spent past due.Two suppliers with the same headline number can have completely different problems. One has customers who cannot pay, the other has invoices that cannot be approved. Only the split tells you which team to staff.
Terms adherence gapThe distance between the terms you agreed and the days you actually collect, measured per customer rather than in aggregate.Agreed terms on the customer master and the sales order, against the actual clearing date on the receipt.The Western Europe appendix shows 65% of respondents setting terms under 30 days and 62% reporting annual average days sales outstanding under 30 days. At portfolio level the gap is small. At customer level it is where the concentration hides.
Invoice completeness at releaseThe share of invoices that carry every field the customer’s approval workflow requires, checked before release rather than after rejection.A per customer field requirement set, held as data, validated at billing release.This is the cheapest of the four to build and the fastest to show a result, because the rule already exists. It is currently stored in the memory of whoever handles that account.

First pass approval rate is the one most worth starting with, because it is the only measure on the list that scores the supplier’s own output rather than the customer’s behaviour. It also changes the tone of a difficult account conversation, since it moves the discussion from asking a customer to pay faster toward asking them what their approval workflow needs, which is a question most buyers are happy to answer.

An implementation checklist.

  1. 1.Write down what each of your twenty largest customers requires on an invoice before it can be approved. Purchase order reference format, cost centre, buyer contact, legal entity, attachment, portal, tax fields. Most order-to-cash teams already know this. Almost none of them hold it as data, which means it is applied by whoever happens to handle that account and lost when they move on.
  2. 2.Validate those requirements at billing release rather than discovering them at rejection. A billing block that fires because a required reference is missing costs minutes. The same invoice discovered by the customer costs a full approval cycle, and the surveys suggest that cycle is where a real share of the delay lives.
  3. 3.Give the dispute reason a code and make it mandatory. A collector note that says chasing again is not data. A code that says the purchase order reference did not match is a queue you can work, a rule you can add, and a number you can take to a monthly review.
  4. 4.Split the ageing by cause before staffing against it. Liquidity cases need a credit conversation and possibly a provision. Approval cases need a billing fix. Dispute cases need order and delivery data reconciled. These are three different teams doing three different jobs, and one aged trial balance sorted by days hides all of it.
  5. 5.Make the due date reflect how the money actually travels. If a customer pays by a method that settles in three days across a corridor, an invoice dated to the day the money leaves their account will always read as late in your ageing, and your collectors will chase a customer who paid on time. Set the convention deliberately, per method and corridor, and record it.
  6. 6.Hold one set of remittance instructions per selling entity and currency, generated from master data rather than typed into a template. Payment mechanics is a named cause in every region and the highest ranked of the fixable ones in Asia at 25%. It is also the cheapest thing on this list to get right.
  7. 7.Reconcile the order, the delivery, and the invoice before the invoice goes out, not after the customer does it for you. Where the three records can disagree, a validation at billing is a control. Where they cannot, you have already removed a dispute category.
  8. 8.Review credit limits on a schedule rather than on an incident. Customer liquidity is the cause you cannot design around at invoice time, which is precisely why the decision belongs at order acceptance, with an exposure based release rule that does not depend on anyone remembering.
  9. 9.Measure first pass approval rate per customer and publish it. It is the single number that tells an order-to-cash team whether its own output is working. It also reframes the conversation with a slow paying customer, because it moves the discussion from chasing to fixing something specific.
  10. 10.Keep the terms field honest. Agreed terms belong on the customer master and the sales order, overrides belong in an approval trail, and the gap between agreed terms and actual collection belongs in a report someone reads. The portfolio gap is usually small, which is what makes the customer level gaps worth finding.

Risks and failure modes.

  • Reading customer cash flow as the whole story. It is the largest single answer everywhere, and it is genuinely outside a supplier’s control at invoice time. It is also the reason most easily offered by a buyer who simply has not approved the invoice yet, which is why the other codes need to exist for a collector to reach for.
  • Treating the survey ranking as a ranking of impact. These are multiple response questions about how often a cause is named, not a measure of how many days each cause costs. The order tells you where to look. Your own reason coded ageing tells you what it is worth.
  • Building a reason taxonomy with forty codes. A taxonomy that a collector has to think about will be answered with whichever code is at the top of the list. Seven codes that map to real owners will be used. The point of the code is that someone can act on it, so if no team owns a code, it should not exist.
  • Chasing the ageing without splitting it. A single aged trial balance sorted by days gives every overdue invoice the same treatment, which means the disputes get chased and the liquidity cases get chased and neither gets resolved. Sorting by cause is a change to a report, not a system programme.
  • Assuming your invoices are fine because customers eventually pay. Eventually is the measurement. An invoice that is resent once and then paid on time looks perfect in the ageing and consumed a full approval cycle plus two people’s attention. First pass approval rate is what makes that visible.
  • Letting terms overrides happen in the order rather than in a decision. Terms that can be changed on a sales order without an approval trail turn the customer master into a suggestion, and the terms adherence gap becomes impossible to interpret because you no longer know what was agreed.
  • Confusing a portal with a process. Sending invoices into a customer’s procurement portal solves delivery. It does not solve whether the fields inside the invoice match what the portal will accept, and a portal rejection is usually quieter than an email one.
  • Expecting the macro numbers to help. Global payment terms have been roughly flat since 2022 at around 56.5 days. There is no rising tide here to blame or to wait out, which is the good news, because it means the spread between suppliers is made of decisions rather than conditions.

Data and interface considerations.

  • The customer master is where terms, credit limit, release rule, invoice delivery channel, and required reference fields all belong. Holding any of them in a spreadsheet beside the ERP is what turns an account handover into a month of avoidable disputes.
  • The dispute or deduction record needs a coded reason, a value, an owner, and a link back to the invoice and the order line. Without the link back to the order line, a price dispute cannot be traced to the price list entry that caused it, and the same dispute returns next quarter.
  • Cash application matching quality is a leading indicator, not a back office statistic. An unapplied receipt is an invoice that looks overdue while the money sits in your bank, and it will be chased by a collector who has no way of knowing.
  • Proof of delivery and service records need to be reachable from the invoice, ideally by reference rather than by attachment. The dispute cause that Asia respondents named second is settled by producing that record quickly, and a link is faster than a search.
  • Reference data flowing out matters as much as data flowing in. The payment reference you print is the reference your customer’s system will carry, and if it is regenerated at any point in your billing chain you have created a matching failure that will surface as an unapplied receipt weeks later.
  • Interfaces to customer portals and e-invoicing networks should surface rejections into the same queue as any other exception. A rejection that lands in a mailbox nobody owns is functionally an invoice that was never sent.

The audit evidence this produces.

A pleasant side effect of coding the causes is that the receivables file becomes easier to defend. Expected credit loss work depends on distinguishing a receivable that is contested from one that is simply unpaid, and most ledgers cannot make that distinction without somebody reading collector notes. These are the records worth being able to produce as at a date.

  • Credit limit decisions with the date, the approver, the exposure at the time, and what changed. This is the evidence that supports both the release rule and, later, the provision.
  • Terms overrides against the customer master default, with who approved them. Where terms can move without a trail, the expected credit loss model is being fed a number nobody can reconstruct.
  • The dispute record with its coded reason, its value, its age, and its resolution. Coded disputes are also the cleanest input to an expected credit loss assessment, because they separate a receivable that is contested from one that is simply unpaid.
  • Credit note approvals with the dispute they resolve. A credit note issued without a linked dispute is a revenue reversal with no explanation attached, which is the version an auditor will ask about first.
  • The ageing itself, reproducible as at a date, with the cause split preserved. An ageing that can only be produced live is evidence of today rather than evidence of the period.
  • Cash application decisions where a receipt was matched by judgement rather than by reference. These are the entries most worth being able to explain, and they are usually the ones with the least written down.

Questions worth asking in your own review.

  • For our twenty largest customers, what does each one require on an invoice before it can enter their approval workflow, and where is that written down as data rather than as knowledge?
  • What share of our invoices are approved by the customer on the first send, without a query, a resend or a correction? If nobody can answer, what would it take to instrument it this quarter?
  • When a collector records why an invoice is overdue, is the answer a code or a sentence? If it is a sentence, how would we count the ones caused by our own invoice?
  • Can we split the current overdue balance into liquidity, approval friction, dispute, and payment mechanics? What percentage falls out as unclassified?
  • Which of our disputes trace back to a difference between the order, the delivery, and the invoice, and which field differed most often last quarter?
  • Does the due date on our invoices account for how the customer actually pays, per method and per corridor, or does it assume same day settlement everywhere?
  • How many sets of bank details does a customer of ours encounter across our selling entities, and are they generated from master data or typed into a document template?
  • Can somebody change payment terms on a sales order without an approval trail, and if so, how do we know today what was actually agreed with that customer?

What this adds up to.

The most encouraging number in the whole 2026 set is the plainest one. In Western Europe, 23% of respondents report that none of their B2B invoices are paid late, and in the United Kingdom that figure is 34%. Those suppliers are selling into the same economies, to the same buyers, under the same financing conditions as everyone else. Whatever separates them is not luck and it is not the macro environment, because the macro environment has been broadly flat since 2022.

What the survey gives you is an unusually direct account of what that difference is made of. One cause you can only influence at the credit decision. Three you can influence at the billing decision, by putting the right references on the invoice, sending it where the approver actually works, keeping the remittance instructions simple, and making sure the order, the delivery and the invoice agree before the customer has to point out that they do not. None of that is a transformation programme. It is a field list, a validation, a coded reason, and a report sorted by cause instead of by age.

Start with the reason code, because everything else on this list gets easier once the ledger can tell you which problem you actually have. Give it a month, look at the top code by value, and you will have a specific, owned, buildable piece of work rather than a general instruction to chase harder.

Sources.

Every survey figure quoted here was read from the Atradius report PDFs and statistical appendices themselves rather than from a summary of them, including the four named reasons and their percentages, the exposure clusters, the past due timing breakdown, the bad debt distribution, the trade credit share, the payment terms and days sales outstanding bands by company size, and the sample sizes and survey design for each region. Where the regional report and its statistical appendix differed by a rounding point on a single band, no figure from that band has been used. The Allianz Trade figures were read from the published report page directly. The two posts on X quoted above were each verified as public, current and relevant before being cited, with the author, handle, date and wording confirmed against the live posts, and neither has been paraphrased into something it did not say. The reason taxonomy shown above is a worked example of the shape being described and is not an extract from any customer system. Percentages from a multiple response question describe how often a cause was named, not how many days of delay it caused, and nothing here should be read as attributing a share of days sales outstanding to any one cause.