Trade Health Methodology
Version 1.1Β·Effective July 1, 2026
BM-THM-v1.1
This page describes how Berry Marketplace computes the Trade Health Score displayed on every Company profile, listing card, and offer surface across the platform. It documents how Berry has interpreted Section 7 (Reputation System) of the Platform Terms since those Terms took effect, and is published here for transparency. It is not itself a contract and does not require acceptance.
What the Trade Health Score is
The Trade Health Score is a number between 0 and 100, computed by Berry from a Company's verified trading history on the Platform. It is shown alongside (and never blended with) user-authored reviews, so that counterparties can read two distinct signals at a glance:
- Stars β what other Companies have said about a Company, in their own words.
- Trade Health β what a Company's own trading record says about them, computed by Berry from objective events.
A Company's score is updated automatically whenever a trading event that feeds the score occurs (a contract completes, a dispute resolves, an invoice is paid, a delivery is recorded). A daily backstop recompute runs at 06:30 UTC to catch any events the live triggers may have missed.
The score, the band it falls into, and a per-component breakdown are visible on every Company profile. Companies can view the individual events feeding their own score on the My Company β Trade Health activity tab.
Bands
| Score | Band |
|---|---|
| 90β100 | Excellent |
| 75β89 | Good |
| 60β74 | Fair |
| Below 60 | Needs attention |
| Fewer than 3 completed contracts | Insufficient trading history (no published score) |
A Company with fewer than 3 completed contracts on the Platform shows "Building (X of 3)" instead of a score. This avoids penalising new Companies for thin data. Once the threshold is reached, the score appears.
Components and weights
The score is the weighted average of four components. Weights sum to 1.00.
| Component | Weight | What it measures |
|---|---|---|
| Dispute Rate | 35% | The fraction of completed contracts that ended cleanly versus those that involved a quality issue or dispute, weighted by outcome severity. |
| On-Time Delivery | 25% | How close to schedule a Company's deliveries arrive (seller-side signal). |
| Commission Payment Timeliness | 20% | Whether a Company pays Berry's per-trade commission invoices on or before due date (buyer-side signal). |
| Dispute Response Rate | 20% | Whether a Company engages with disputes filed against them within the dispute's response window. |
Each component is computed independently as a value between 0.0 and 1.0, then multiplied by its weight. The component values are summed and divided by the total weight of components that have at least one event for the Company. The result is multiplied by 100 to produce the displayed score.
If a Company has no events for a given component (for example, a Company that has only ever sold has no commission-payment history), that component is excluded from both the numerator and the denominator β it neither helps nor hurts the score.
How time affects the score
Trade Health uses a dilution model, not a decay model. This is an important distinction.
A decay model would say: "Old events count less over time." Berry does not do this. Old events count fully, indefinitely.
A dilution model says: "Every new completed contract adds to your record, and your overall ratio improves automatically as your good behaviour accumulates." This is what Berry does.
The practical effect is that a Company with one old issue and many subsequent clean trades sees their score climb naturally β the issue is not erased, but its arithmetic weight as a fraction of the Company's total trading history shrinks with every clean contract added. You can trade your way out β every clean contract dilutes the impact of any prior issue, without ever pretending the issue did not happen.
We do not "forget" old events. A 3-year-old dispute counts at the same arithmetic weight as a 1-month-old dispute. What changes is the share that event represents of the Company's total record.
A future version of this methodology may introduce a symmetric recency overlay (older events weighted slightly less than recent events) if data later shows it improves the signal for dormant Companies. If introduced, it will be a symmetric overlay only β never a curve that amplifies recent events disproportionately. Any such change will be published as a new version of this page (v1.1, v2.0, etc.) under Section 7.3 of the Platform Terms, which reserves Berry's discretion over methodology evolution.
A future version may also introduce Bayesian shrinkage β a statistical technique that reduces score volatility for Companies near the 3-contract floor by gently pulling their ratios toward the platform-wide average. v1.0 uses a simple cutoff (no score published below 3 contracts); v2.0 will likely soften this with shrinkage above the floor. We disclose its absence in v1.0 so its eventual addition is not a surprise.
Component details
Dispute Rate (weight 35%)
Source: every contract that reaches COMPLETED status. Each completed
contract emits one row per affected party (the buyer and the seller),
and the row's value is determined by the worst quality outcome on that
contract. Clean trades count fully; trades with quality issues or
disputes count proportionally less, depending on how the issue was
resolved and which party was at fault.
| Outcome on the contract | Value for the at-fault party | Value for the counterparty |
|---|---|---|
| Clean trade β no quality issue, no dispute | 1.00 | 1.00 |
| Quality issue resolved bilaterally (no formal dispute filed) | 0.85 | 0.85 |
| Dispute β claim withdrawn (typically resolved off-platform) | 1.00 (respondent) | 0.95 (initiator) |
| Dispute β no action agreed (claim mutually dismissed) | 0.95 (respondent) | 0.92 (initiator) |
| Dispute β fault acknowledged, full restitution (refund or replacement) | 0.50 | 1.00 |
| Dispute β partial refund agreed with fault attribution | 0.50 | 0.95 |
| Dispute β resolved with no party at fault (compromise) | 0.70 | 0.70 |
| Dispute β referred to external arbitration | 0.60 | 0.60 |
| Dispute β claim expired (no engagement, aged out) | 0.10 (respondent) | 0.50 (initiator) |
A few notes on how to read this table:
- A fairly resolved dispute still counts something. A seller who delivered a replacement after a legitimate complaint scores 0.50 on that row, not 1.0. The replacement was the correct response, but a real issue happened, and the score reflects that. Replacement, full refund, and store credit are treated equivalently β fault attribution is the same regardless of the form restitution takes.
- Withdrawn claims are read charitably. When a claim is withdrawn, the most common reason is off-platform amicable resolution. The respondent gets a clean 1.00; the initiator gets 0.95.
- Ignoring a complaint is the worst routine outcome. A respondent who lets a claim expire without engaging scores 0.10. The initiator who walked away too gets 0.50.
- External arbitration is held at 0.60 for both until the arbitral outcome is recorded back to the Platform, at which point the score is recomputed from that outcome.
On-Time Delivery (weight 25%)
Source: every recorded delivery (contract_deliveries row that
delivered). Days late is calculated as actual delivery date β scheduled date, capped at zero (early deliveries score the same as on-time).
| Days late | Value |
|---|---|
| 0 (on or before schedule) | 1.00 |
| 1β3 days | 0.70 |
| 4β7 days | 0.40 |
| 8β14 days | 0.20 |
| 15+ days | 0.10 |
This signal is seller-attributable: only the seller's score is affected.
Commission Payment Timeliness (weight 20%)
Source: every commission invoice (Berry's per-trade fee charged to the
buyer) with status PAID. Days late is calculated as paid date β due date, capped at zero.
| Days late | Value |
|---|---|
| 0 (paid on or before due) | 1.00 |
| 1β3 days | 0.80 |
| 4β7 days | 0.40 |
| 8β14 days | 0.20 |
| 15+ days | 0.10 |
Slightly more lenient than on-time delivery for the 1β3 day band only β SEPA bank settlement legitimately takes 1β2 days. The curves converge from day 4 onward, where banking-delay explanations no longer apply.
This signal is buyer-attributable: only the buyer's score is affected.
Subscription invoices are not part of Trade Health. Berry's monthly or annual platform subscription is a commercial relationship between each Company and Berry, separate from how that Company is presented to counterparties. Folding subscription dunning into a counterparty-facing reputation metric would conflate two unrelated relationships, so we do not.
Buyer-to-seller contract payments are also not part of Trade Health. These payments happen off-platform (typically by direct bank transfer) and Berry does not have authoritative records of when they cleared. If Berry's role in mediating contract payments expands in future product lines, this component may be added.
Dispute Response Rate (weight 20%)
Source: every dispute filed against the Company (where this Company is the respondent).
| Response behaviour | Value |
|---|---|
| Responded within the dispute's response window | 1.00 |
| Responded after the window but before resolution | 0.50 |
| Did not respond at all | 0.00 |
The response window is read per dispute from the dispute's
respondentDeadline field β it is not a hard-coded 7 days. B2B
agricultural disputes legitimately need variable response windows for
sample testing, lab analysis, holiday seasons, and force-majeure
situations, and the system accommodates these. The relevant question
is not "did you respond within 7 days?" but "did you respond within the
window that applied to this specific dispute?"
Adjustments β input correction by Berry Operations
Section 7.3 of the Platform Terms states that Companies may request a review of factual inaccuracies affecting their reputation score. Berry exercises this discretion through a single mechanism: excluding individual events from the score's input set.
We never type a different number into a Company's score. The score is always the deterministic result of a formula applied to a set of events. What Berry Operations can do β and only Berry Operations, through an audited workflow β is mark a specific event as not counting, with a named reason and a permanent audit record.
The closed set of reasons under which Berry Operations may exclude an event from a Company's score:
| Reason | When applied |
|---|---|
| Platform bug or recording error | Berry's own systems caused the problem, or the system mis-recorded an event (a delivery was on time but logged as late, an integration miscounted a payment). Both data-side and platform-side faults sit under this single reason β the audit row's free-text note disambiguates. |
| Counterparty fraud confirmed | The counterparty was acting in bad faith and the event reflected that, not this Company's behaviour. |
| Force majeure | A port strike, customs lockdown, weather event, or comparable circumstance affected the trade through no fault of either party. |
| Off-platform side deal | The parties resolved the trade off the Platform (typically by direct contact) and the on-platform record no longer reflects what actually happened. The on-platform event is misleading and should not feed the score. |
| Other (documented) | Anything else; the operator must justify the exclusion in writing in the audit record. The free-text note is required. |
Internal-only categories. A separate non-public reason β test or
demo data β exists in the database for scrubbing staging fixtures that
leak into production. It never reflects real Company behaviour, is not
applied to live trades in normal operation, and is documented here for
completeness rather than as a reason a Company would ever encounter on
their own audit row. If you see a TEST_OR_DEMO exclusion against a
real trade, contact support β it is almost certainly an Operations
mistake we want to know about.
Each exclusion is logged in an append-only audit table that cannot be edited or deleted, even by Berry Operations. The Company whose score is affected can see their own list of exclusions on the My Company β Trade Health activity tab, with operator names redacted to "Berry Operations team" for operator privacy. The Company can request review of an exclusion (or argue for one) through the linked CRM ticket.
Excluded events are silently absent from the public-profile breakdown panel (a Company with one excluded dispute and 19 clean contracts displays a 5% dispute rate, not "5% with one exclusion"). The audit trail lives where audits belong β in CRM, and in the affected Company's own Trade Health activity tab. Public profiles show the cleaned, defensible score.
Integrity violations β confirmed fraud, account suspension followed by reinstatement, repeated-pattern violations β are handled differently from routine signals. They count at full weight indefinitely and are not subject to the dilution mechanic described above. v1.0 has no integrity events implemented yet, but the framework is disclosed here so that a Company encountering one in the future does not see it as a retroactive change.
Right of factual review
A Company that believes a specific event is recorded inaccurately and should not be counted toward their Trade Health Score may request review through the support channel linked from their My Company β Trade Health activity tab. Berry Operations reviews the request against the five reasons above, applies the exclusion or denies the request, and records the decision in the audit log. Berry is not obligated to modify scores resulting from verified transactional outcomes or documented disputes (per Platform Terms Section 7.3, second sentence).
Scope and disclaimer
Reputation scores are informational indicators only and do not constitute legal judgments. They are visible to other Platform Users under Platform Terms Section 7.2(a). Berry reserves discretion over calculation methodology, which may evolve over time, under Platform Terms Section 7.3.
Trade Health is computed only from events on the Berry Platform. Trading history, references, certifications, or reputation a Company may have outside the Platform is not included.
The Trade Health Score does not currently affect search ranking or matching results. If that changes in a future version of the Platform, this page will be updated and the change disclosed.
Previous versions
Version 1.1 (1 July 2026) migrated this page to the platform's HTML rendering, with no change to the methodology. Version 1.0 (20 November 2025) was the first published version of this page.