One Person, Two Ledgers: Netting Input Credit Against a Produce Payment
A co-op member you sell fertiliser to and buy maize from is one person and two completely separate records — a customer with a receivable and a vendor with a payable. Nothing in the system knows they are the same human being. What it costs, the two instruments that get you most of the way, and the accounting hole in one of them.
Every co-operative and every aggregator runs the same two-way relationship with the same person. You sell them inputs on credit in March. You buy their produce in September. In the accounts, one of those makes them a debtor and the other makes them a creditor, and in the yard they are just Mama Wanjiru with a receipt book.
The instinct is to net it: take what she owes for fertiliser off what you owe her for maize, pay the difference, and be done. That is exactly what a check-off is, and it is how this business has been run since long before anybody had software. The question this article answers is what actually happens when you try to do it in a system that stores the two sides in two unconnected places.
The two records, and why they never meet
A person you sell to is a customer: name, phone, currency, a credit limit, an opening balance, and invoices raised against them. A person you buy from is a vendor: name, phone, M-Pesa number or paybill, bank details, and payments made to them. Both are ordinary, well-built records. Neither carries a reference to the other.
That is not an oversight so much as a consequence of how the two halves of any business are usually shaped: your customers are rarely your suppliers. Agriculture is the exception, and it is the exception at scale — for a co-op, most counterparties are both. So the gap that a distributor would never notice is the one that defines your month-end.
What exists on each side of one member
Member as customer
A customer record with a credit limit and an opening balance you type. Invoices for inputs issued, aged and reported. An invoice that would push their exposure past the limit is held on credit hold with the amount it exceeded by, releasable by an override that records who overrode it and why. Statements, arrears and reminders all work from here.
Member as vendor
A vendor record with the payout details that matter in this market: M-Pesa phone for B2C, paybill or till for B2B, bank code and account. Payments to them are recorded in the Payments Register with a method, reference, amount and status, and appear in money-out reporting.
The link between them
There is no field on either record pointing at the other, no shared party identifier, and no screen that shows one person's receivable and payable side by side. You know they are the same person; the system does not, and no report will ever tell you.
Automatic netting on payment
Nothing deducts an outstanding input invoice from a produce payment. A payout pays what you tell it to pay. The deduction is arithmetic you do before you type the amount — and the record of why the amount was reduced lives wherever you choose to put it.
Member record, member number, produce ledger
Worth restating because it is the foundation the rest of this rests on: there is no member entity, no intake ticket, no grade, and no per-kilo calculation. This article is about the money once you know what it is, not about capturing the delivery — that gap is covered in member produce intake.
Read the pattern in the first two rows before the last three. The individual pieces are genuinely there and genuinely good; what is missing is that they know nothing about each other.
The [credit note](/glossary/credit-note) is the instrument you are looking for
A credit note reduces a customer invoice without cash moving. Issue one against Mama Wanjiru's fertiliser invoice for the value of the maize she delivered, apply it, and the receivable falls. That is a netting-off, recorded, numbered and dated, and it is the closest thing to a check-off that exists here.
It has a number of its own, a reason field, an issue date, an application date and three states — issued, applied, cancelled. An applied note cannot be cancelled, which is the right guard: once it has reduced a balance it is part of the record.
Found while writing this, and fixed
A credit note larger than the invoice balance used to apply what fitted and then close itself, discarding the difference in silence — a 5,000 note against a 2,000 balance credited 2,000 and destroyed 3,000. There is no column that holds a partly-consumed note, so the application is now refused with a message naming both figures. Issue a note for the amount you intend to credit, or apply it to an invoice with a balance large enough to absorb it.
The hole you must know about before you rely on it
Here is the part to take to your accountant rather than discover in an audit. Applying a credit note posts no journal entry. It reduces the invoice's balance due and increases its paid amount, and writes nothing to the ledger.
A cash receipt against the same invoice does post a journal entry. So the two ways of settling an invoice behave differently in the books: receipts reconcile, credits do not. Two consequences follow, and both matter more the more netting you do.
- Your receivables control account will not agree with your invoice list. The invoices say the balance came down; the ledger was never told. The difference is exactly the total of applied credit notes.
- A credit note reads as money collected. Because the application increases the invoice's paid amount, anything that measures collections from that figure counts a netting-off as cash received. Your cash-in number is overstated by the value you netted, which in a season of heavy check-off is not a rounding error.
This is in the gap register as a finance item needing a decision rather than a quick patch, because posting the entry correctly means choosing which account the credit lands in, and that is a chart-of-accounts question specific to you, not something to guess at in a controller. Until it is closed, treat netting as an operational record and pass the total to your accountant as a manual journal each month.
Receipts reconcile; credits do not. If you net heavily, the difference between your invoice list and your ledger is the exact size of your netting.
What the month actually looks like
One member, one season, netted by hand
Illustrative figures. Three documents, two records, one person, and one manual journal owed to your accountant. The arithmetic is trivial; the discipline is making sure the same three documents are produced every time, by everybody, in the same order.
The order matters more than you would think
Do it in the wrong sequence and you cannot reconstruct it later. Pay her the full 41,000 first and then chase the 28,400, and you have converted a settled account into a debt collection — which is precisely the outcome check-off exists to prevent.
The sequence that survives an audit is: value the delivery, credit the invoice, then pay the residue. Each step leaves a numbered document, and the payment reference carries the credit note number so the two sides can be tied together by a person, since no query will do it for you.
Put that reference discipline in writing before the season starts. A payment reference reading "September maize" is worthless six months later; one reading "CR-0184 net of inputs" reconstructs the whole transaction from either end.
The credit limit is the control you are not using
The input-credit failure mode is not usually theft. It is a member who has taken more inputs than their expected harvest can cover, agreed to informally, in three separate transactions, by three different people who each saw only their own.
A credit limit on the customer record turns that into a stop. Exposure is computed as the opening balance plus every open invoice, so the fourth request is held and flagged with the amount it would exceed by — visible, overridable, and with the override recorded against a name and a reason. That is not a per-member credit-scoring engine, which does not exist here. It is a ceiling and a paper trail, which is most of the value.
Set it from the acreage they have registered and the price you expect, then review it once a season. A limit nobody revises becomes a limit everybody overrides, and an override that happens every time has stopped being a control.
Questions to settle before the season, not during it
Who values the delivery, and against which price list?
What good looks like
One named role, one written price per grade per week, posted where members can see it.
If the answer is otherwise
There is no supplier contract or agreed price list in the system, so an invoice price is never checked against a rate. If the price lives in somebody's head, the netting is a negotiation at the scale.
Who is allowed to issue a credit note?
What good looks like
A short list, separate from whoever values the delivery.
If the answer is otherwise
One person valuing and crediting is the whole control in one pair of hands. The permission is there — use it to split the two.
Where does the credit note number appear on the payout?
What good looks like
In the payment reference, every time, no exceptions.
If the answer is otherwise
Nothing links the payable and the receivable automatically. Without the reference the two halves are only connected by memory.
Who passes the netting total to the accountant, and when?
What good looks like
A named person, monthly, from the credit-note list.
If the answer is otherwise
Applied credit notes are absent from the ledger. If nobody carries that number across, the receivables control account drifts all season and is reconciled in a panic at year end.
What happens when the harvest is worth less than the inputs?
What good looks like
A written policy: carry it forward, or write it off, decided in advance.
If the answer is otherwise
There is no member debt account to carry a balance in, so the residue stays as an open customer invoice — which will start emailing them arrears reminders if they have an email address on file.
What we do and do not do
What AWRA OpsHub does today
- Customer and vendor records that each do their own job properly, including M-Pesa B2C payout details on the vendor side and a credit limit on the customer side.
- Credit notes — numbered, dated, reasoned, applied against a specific invoice, three states, and an applied note cannot be cancelled.
- Credit-limit exposure with a hold and a recorded override, computed from the opening balance plus all open invoices.
- Customer statements you can filter by date and email out with your own subject and message.
- Overdue-invoice reminders to the customer, scheduled daily — and, from this batch, switchable off or slowed to weekly or monthly per organization, which previously ran ungated.
What it does not do
- No link between a customer and a vendor record. One person is two records and nothing joins them, in either direction, anywhere.
- No automatic netting or check-off. Every deduction is arithmetic you perform before typing an amount.
- No journal entry when a credit note is applied, so the receivables ledger and the invoice list diverge by the amount you net, and the credit is counted as cash collected. Carry the total across manually until this is closed.
- No bulk member payout run. M-Pesa pays out — B2C to a phone, B2B to a paybill or till — one payment at a time, to a vendor.
- No member entity, produce intake, grading or per-kilo pricing. The value of the delivery is a figure you arrive at outside the system.
- No credit scoring, eligibility rules or seasonal credit cycle. A limit is a number you set and review; nothing derives it from history.
The journal-entry gap is the one to act on this week: it is small in effort and large in consequence, and it is the only item here that quietly makes a report wrong rather than simply absent. Everything else on the not-built list is visible work you know you are doing by hand.
Running it properly, in five decisions
- Register every member twice, deliberately — as a customer and as a vendor — with the same identifier in both names so a human can match them at a glance.
- Set a credit limit on every customer record before the input season opens, derived from acreage and expected price.
- Separate the person who values a delivery from the person who issues the credit note.
- Make the credit note number part of the payout reference, and audit ten payouts a month for it.
- Book the month's applied credit notes as one manual journal, and reconcile the receivables control account against the invoice list before you close.
None of that is exotic. It is the same discipline a co-op clerk with a ledger book and a carbon receipt has always run, which is worth saying plainly: the value here is that each step leaves a numbered, dated, attributable document instead of a line in a book only one person can read.
Our take
Netting a member's input credit against their produce payment is workable today with credit notes, and the paper trail is genuinely better than the receipt book it replaces. Two things are on you: the manual journal that keeps your ledger honest while credit notes stay outside it, and the reference discipline that keeps the payable and the receivable connected, because nothing in the system knows they belong to the same person.
See customers, credit limits and statements
Credit limits with holds and recorded overrides, credit notes against invoices, statements you can email, and arrears reminders you control the cadence of.
Explore the customer viewFrequently asked questions
Can the system deduct what a member owes from what we pay them?
Not automatically. A customer record holds what they owe and a vendor record holds what you pay, and nothing joins the two — so the deduction is arithmetic you do before typing the payment amount. The instrument that records it properly is a credit note against their input invoice, which reduces the receivable without cash moving. Do that first, then pay the residue, and put the credit note number in the payment reference.
Why do we have to register a member twice?
Because the two sides of the relationship live in two different records with no link between them: a customer for what they buy from you, a vendor for what you buy from them. Use the same membership number in both names so a person can match them instantly, since no report will. It is duplication, it is visible, and it is the honest position rather than a hidden one.
Does applying a credit note appear in our accounts?
No — and this is the most important line in this article. A cash receipt against an invoice posts a journal entry; applying a credit note does not. The invoice balance falls, the ledger is not told, and the invoice's paid amount is increased so the credit also reads as cash collected. Until that is closed, book your applied credit notes as a manual journal each month and reconcile the receivables control account against the invoice list before closing.
What happens if a credit note is bigger than the invoice?
It is refused, with a message naming both figures. It used to apply what fitted and close itself, silently discarding the difference — there is no column for a partly-consumed note, so a partial application had nowhere to keep the residue. Issue a note for the amount you actually mean to credit, or apply it to an invoice with a balance large enough to absorb it.
Can we pay all our members in one run?
No. M-Pesa does pay out as well as in — B2C to a phone number, B2B to a paybill or till, with the transaction landing on the Payments Register — but it pays a vendor, one payment at a time. There is no bulk member payout run, no batch file and no payout schedule. At a few dozen members that is an afternoon; at several hundred it is the constraint that decides whether this fits your co-op.
How should we set a member's credit limit?
From their registered acreage and the price you expect, reviewed once a season. Exposure is computed as the opening balance you typed plus every open invoice, so the limit does real work: the request that breaches it is held and flagged with the excess amount, and the override records who released it and why. Nothing derives a limit from delivery history — there is no credit scoring — so it is a judgement you make and revisit deliberately.
Will a member with an unpaid input invoice be chased automatically?
Yes, if they have an email address on the customer record — an overdue-invoice reminder goes out on a schedule once the due date passes. That is worth knowing before you leave a residual balance open after a poor harvest: unless you change the setting, the reminder will keep going. The cadence and the on/off switch now sit with the other notification settings, which they did not before this batch.
