The Saturday market used a modest payment tool for pre-orders. Stallholders confirmed what they could supply, the shared office calculated each basket, and customers received a charge after collection. It made the queue shorter and the accounts easier to reconcile. Then, in one week, it charged a customer twice after a phone substitution and marked a baker’s account overdue even though the market had agreed that her festival takings could be settled later. The quick fix seemed obvious: add stronger reminders, freeze accounts automatically, and identify people who changed orders too often. Instead, the market paused the upgrade. Before giving the tool more power, it wanted to know what kind of decision an automated payment system should be allowed to make.
That distinction matters because payment data has a long shadow. An amount, a return, a delayed transfer, and a repeated order may be enough to correct a receipt. Together, they can also be used to create an unspoken judgement about a customer or a trader. In a small market, that judgement follows people into the next week’s conversation. A payment check designed to protect common funds can become a system that treats ordinary exceptions as evidence of bad character. The review therefore had two aims: catch genuine accounting mistakes, and prevent the automation from turning uncertainty into reputation.
Trace the payment path before changing a rule#
The group began with a wall chart, not a dashboard. It traced an order from selection to stall confirmation, calculation, collection, charge, and bank reconciliation. At every point, they asked what could go wrong and what evidence could answer the question. A duplicate charge could be tested against the payment reference, amount, and date. A mismatch could be checked against the confirmed basket. But a late collection, an agreed instalment, or a replacement made when produce ran out could not be interpreted from a number alone.
The group began with a wall chart, not a dashboard. It traced an order from selection to stall confirmation, calculation, collection, charge, and bank reconciliation.
The exercise exposed a basic mistake in the original design: the same “unpaid” status covered very different situations. It could mean a card had failed, a customer had chosen the agreed cash route, a bank had delayed a transfer, or the application had retried a connection. Treating all of them as overdue is not neutral simplification. It hides the cause while attaching a negative signal to the person at the end of the record. The market required every future rule to say what observable event it found, what it could not infer, and who would check the context before any adverse action.
Keep automation attached to transactions#
The audit retained a narrow set of automated checks. One compared reference, amount, and timing to identify likely duplicate charges. Another checked that the charged total matched the confirmed order. A third flagged a refund larger than the authorised return, and a fourth found shared fees applied twice. These rules were useful because each pointed to a specific transaction. The reviewer could see the two records that created the discrepancy, correct an entry, and close the matter without opening a dossier on anyone.
The market also wrote down what the tool could never do. It could not generate a trust score, rank people by the number of order changes, mine support messages for explanations, or use resolved alerts to predict future non-payment. This was not a technical nicety. A transaction rule asks whether two pieces of evidence match. A behavioural profile claims to know whether a person is reliable from traces that usually lack their context. The former supports repair; the latter can quietly reshape who is treated as welcome.
Language on the screen changed as well. “Review possible duplicate” replaced “suspicious charge,” and “confirm order total” replaced “customer error.” Descriptive wording makes a reviewer look for cause and remedy. Accusatory wording makes them look for blame. Each alert also named the responsible role, the review deadline, and the option to record that no action was needed. A notification without an owner is not accountability; it is only a way to pass anxiety along.
Give exceptions a human route#
Some cases could not be fixed by comparing two fields. Those entered an exception queue reviewed by a rotating pair: one person from the stalls and one from the shared office. They were allowed to see only what the case required. To assess a substituted vegetable, they saw the original order and the substitution note, not the customer’s whole buying history. To check a deferred settlement, they saw the agreement and planned date, not every bank movement associated with the stallholder.
The pair had three ordinary outcomes: amend the charge, request a proportionate clarification, or close the alert as legitimate. There was no automatic sanction option. A temporary block required a second review and a reason that could be communicated clearly to the affected person. The resulting record stayed factual: “order 611 was adjusted after a missing crate was confirmed,” rather than “this customer often changes orders.” The first statement can be checked and challenged; the second is a sticky label with little accounting value.
Reviewers also avoided cases involving close neighbours, regular suppliers, or direct competitors. When a case was sensitive, a third trained member was selected. The training was practical rather than ceremonial: distinguish an observed fact from an interpretation, request the minimum information, and notice when many similar alerts are evidence of a poor rule rather than a population of difficult people. Rotating the role spread knowledge and kept payment review from becoming a permanent hierarchy.
Test a proposed rule without making people absorb its risk#
Every new rule operated for four weeks in observation mode. It could produce a report, but it could not change a visible balance, intensify reminders, or stop a basket from being collected. At the end, the market counted how many alerts were genuine mistakes, how many were resolved by a simple correction, and how many represented legitimate situations the rule could not understand. The trial treated configuration as a hypothesis that had to earn its place.
One proposal to flag “unusually late” payments failed this test. It repeatedly highlighted a group of older customers who had an explicit accessibility arrangement to pay at the office on Thursdays. The rule had not found a hidden risk; it had overlooked a practice the market itself had made necessary. It was removed. By contrast, the duplicate-reference rule found several real repeat charges caused by a payment provider retrying requests after a lost connection. The appropriate response was technical repair and prompt refunds, not questioning the customers who had been charged twice.
The market published the trial summary at its monthly meeting. It reported false positives as well as money recovered. That matters because an automated system can look authoritative simply by producing a large number of cases. If a rule inconveniences many people to solve very few errors, its maintenance cost is not small just because the software runs cheaply. Publishing aggregate results let the community debate proportionality without exposing any individual’s private payment story.
Set a data boundary and a usable remedy#
The final policy listed the fields required for reconciliation: order, amount, reference, date, status, and correction reason. Personal explanations were retained only while necessary to resolve a case, apart from defined accounting obligations. Resolved alerts could not feed a future-risk model. Customers and stallholders could see why an alert existed, submit a correction, and ask for a human review through a route that did not demand a long technical appeal.
The policy also planned for failure. There was an alternative payment route, a named contact, and a way to pause a disputed charge while evidence was checked. A remedy is not a courtesy added after an error; it is part of whether a control is safe to use. Someone who cannot stop an incorrect charge, understand the data behind it, or recover their position promptly has not been given meaningful review.
The market did not abandon automation. It kept the narrow checks that caught duplicate charges and arithmetic mismatches, used people for cases that needed context, and insisted on trial evidence before adding a rule. From then on, any proposal had to include an example of the error it aimed to prevent, the minimum data it required, the expected false-positive rate, and the repair available when it was wrong. That small discipline does more for trust than a score ever could: it makes the system explain why it exists before it asks the community to live with it.
