Managing Accounts Receivable in the System: Maintaining Control

Why system control of receivables is needed

When receivables grow, the problem is rarely one big debt and more often dozens of small issues: an invoice was forgotten to be approved, a payment came partially, part of the amount is disputed, while the shipment has already been sent. As a result, money gets stuck, the financial plan diverges from reality, and instead of managing you end up firefighting.

Manual control in spreadsheets breaks down quickly. A sheet doesn't know that multiple invoices were issued to the same client, that one payment closed only part of the debt, or that another shipment’s due date is tomorrow. Plus human factors: someone didn’t update data, someone missed an email, someone is on vacation. The more sales and shipments, the higher the chance an overdue becomes a surprise.

So controlling accounts receivable in a system is not about pretty automation, it’s about protection from common risks. Usually four mechanisms are enough: clear statuses (normal, due soon, overdue, dispute, partial payment), reminders and escalations, shipment limits and rules, and reports that show the picture for today.

Typical case: phased payment for equipment. The client paid 60%, promised the rest next week, but asks to ship the second batch. Without system control the salesperson only sees the client’s request and finance learns about the default after the fact. In the system, a “partially paid” status and a shipment limit immediately indicate that approval or an exception is needed.

For daily control you don’t need complex formulas. A few metrics are enough: the amount of overdue receivables and its share of the total, top clients by overdue and by amounts approaching due (due in the coming days), number of disputed amounts and how long they’ve been open, and shipments that are blocked or require exceptions.

This approach answers the main question fast: where is the risk, who is responsible, and what action is needed today.

Main objects and roles: who manages what

Working with receivables starts not from reports but from clear accounting objects and defined roles. If cards lack data or it's unclear who approves documents, automation turns into department disputes.

What counts as accounts receivable

Accounts receivable is not just an “unpaid invoice.” In practice it’s a chain of documents and events: an invoice issued, goods shipped or a service provided, an act signed, payment received, a return processed, or an advance offset. The system must link these elements, otherwise you’ll see numbers but not the cause or deadline.

Typically the system tracks invoices and VAT invoices, shipments and delivery notes, goods/services acceptance acts (especially in projects), payments and bank statements, as well as returns, adjustments, offsets and advances.

Minimal set of cards without which control won’t work

For simple control a “skeleton” of several cards is enough. The counterparty card stores details and general terms. The contract sets rules: payment terms, limit, currency, and responsibilities. The invoice records amount and due date. The shipment confirms the liability occurred. A payment closes debt wholly or partly.

If any element is missing (for example, payments entered without linking to invoices), later it’s hard to explain the difference between “debt by invoices” and “debt by shipments.”

Roles and responsibilities: who does what

The same document often passes through several people. To avoid “nobody’s” debts, assign responsibilities in advance:

• Sales: create invoices, verify contract terms, coordinate payment terms with finance.
• Logistics/warehouse: confirm shipment and the status of shipping documents.
• Finance/accounting: upload and reconcile payments, allocate payments to invoices, record advances and adjustments.
• Manager/financial controller: approve limits, exceptions and block rules, and watch key deviations.

Simple example: a client paid 50% of an invoice and sales request a new shipment “on trust.” If the payment is entered and linked to the invoice, the system can show the remaining debt and indicate who needs to approve an exception. This reduces conflict and makes control a daily routine instead of a monthly scramble.

Debt statuses: a simple, clear model

Statuses ensure everyone looks at receivables the same way. Without them one manager calls an invoice “almost paid,” another “problematic,” and financial control wastes time clarifying instead of acting. In the system a status converts discussions into rules: what is visible, who is responsible, and what to do next.

A good status model is short. Often the chain is: new invoice -> awaiting payment -> partially paid -> overdue -> disputed -> closed. It’s important that transitions are unambiguous. “Partially paid” should be set only when money has actually arrived, and “overdue” when the contractual payment date has passed, even if the client promises to pay tomorrow.

What to make a status and what to use a mark for

Status is the main lifecycle stage of an invoice. Keep the set small and avoid many granular variants like “overdue 1–7 days” and “overdue 8–14 days.” Those details are easier to calculate automatically and show as fields.

Make only items that change working rules into separate statuses: overdue (triggers reminders and shipment restrictions), dispute (documents needed, normal waiting paused), and closed (no debt, removed from operational control).

Other details are better as marks (tags or flags): “payment promised,” “payment in transit,” “high risk,” “key client,” “installment agreed.” That keeps the scheme simple while preserving nuances.

How to record reasons and agreements

A common failure: there is a status but no explanation why. Make a rule: any “non-standard” transition (for example, to “dispute” or a manual rollback from “overdue” to “awaiting payment”) requires a reason. This can be a short comment, a reason from a list, and an attached document (email, reconciliation act, claim, amendment).

Example: a client paid 30% and asks to ship more. The invoice gets “partially paid” status and a tag “installment agreed” only after fixing conditions: date of next payment, who confirmed it, and the allowed shipment amount. Then decisions are not verbal but manageable.

Reminders and escalations: don’t miss due dates

Reminders work when tied to clear events. Usually 2–3 triggers cover most situations without drowning users in notifications.

Common triggers: payment due approaching (e.g., 3 days before and on the due date), shipment occurred but payment not received (for prepayment or partial payment deals), and a scheduled payment under a contract timetable (monthly acts, project milestones).

Combine channels. For salespeople, tasks and in-app notifications are convenient: they don’t get lost and are visible in daily work. For clients, template emails (or messages through an internal mail if available) keep communication consistent. For financial control, notify the responsible accountant or finance person so the process doesn’t depend on a single salesperson.

Escalations are not punishment but a way to involve the right person in time. The logic is simple: send reminders, then mark overdue, then involve the manager, and finally legal or security if appropriate. Escalation should kick in when overdue repeats, the sum is significant, or the client stops responding.

Don’t overdo frequency. Daily emails become ignored. A reasonable rhythm: one gentle ping before the due date, one on the due date, then 1–2 reminders in the first week of being overdue, and later less often but with higher-level inclusion (for example adding the manager in copy).

Keep message templates short and calm. Each reminder should include: invoice amount and number (or contract), due date and how many days remain (or passed), next step (how to pay and who to contact with questions), and the contact of the person responsible.

For example, if an equipment invoice is due Friday, the system assigns a task to the manager on Wednesday, sends the client an email on Thursday, and if overdue on Monday includes the sales manager’s head in copy and notifies finance. This makes deadlines less dependent on people’s memory and actions predictable.

Shipment limits: rules, blocks and exceptions

Shipment limits prevent sales from increasing risk when payment is late. This is a clear lever: the rule is known in advance, and decisions are recorded and checked.

Usually several limit types are set because one metric doesn’t reflect the whole situation:

• credit limit: maximum total debt allowed for a client
• overdue limit: acceptable size of overdue debt
• term limit: how many days past due before a block
• order limit: cap on a single shipment for new or risky clients

Then choose reaction modes. A soft block shows a warning to the salesperson and offers approval, but does not stop the process automatically. A hard block prevents shipment until conditions are met (payment, agreed exception, dispute resolved). Soft mode is useful initially; hard blocks work better where shipments equal real risk, e.g., equipment deliveries or large lots.

Account for partial payments and disputed amounts, otherwise limits will trigger incorrectly. After a partial payment the system should reduce the current debt and recalculate available limit immediately. Disputed amounts should be flagged separately: visible in the overall picture but not automatically blocking shipment without a responsible decision.

Exceptions should be rare and transparent, otherwise limits become a formality. A clear scheme: the salesperson requests an over-limit shipment with a reason, finance confirms the risk calculation (amounts, dates, payment history), the manager approves or rejects, the system records the decision and its validity period, and after shipment a task to monitor payment is created automatically.

To avoid breaking sales operations, agree rules in simple scenarios first. For example: up to 7 days overdue — warning only; after 7 days — hard block; disputed amounts do not block but require approval; key clients have higher limits reviewed quarterly.

Reports for financial control: what to check daily

For control to work, reports must answer one question: where is the largest risk today of losing money or failing a shipment.

Start the morning with a short daily overdue snapshot. Look not only at sums but at debt “age”: 1–7 days, 8–30, 31–60 and beyond. Two invoices of 200,000 KZT overdue by 3 days are usually less dangerous than one invoice of 200,000 KZT overdue for 45 days.

Keep four indicators together and check them on one screen or report:

• total overdue (amount) and change versus yesterday
• overdue by age buckets (how much in each range)
• top-5 counterparties by risk (amount + days + status)
• new “red” cases: who moved to an older overdue category

Next, a counterparty report that shows debt dynamics. It helps distinguish a one-off failure from a systemic problem. For a manufacturer or systems integrator like GSE.kz this is especially important: if debt rises before the next equipment delivery and payments arrive later than usual, it’s better to see that in advance.

The third required layer is a document ledger. It answers which specific invoices, delivery notes or acts are pending and what needs doing: send a copy of invoice, a closing document, clarify payment details, approve an act. When finance says “the client owes 3 million” and sales says “they paid everything,” the issue is almost always at the document level.

Keep a receipts plan for the week and month. It’s built from expected payments and client promises but should live next to facts. Log deviations daily and the reason, otherwise the plan remains a pretty table.

Investigating deviations: quickly finding the cause

Reconcile plan and fact by a short list of causes: delay in document approval, payment date moved, partial payment, retention for a claim, or incorrect payment details. Such a breakdown helps act rather than argue: who to call, which document to send, which task to set for sales or logistics.

Step-by-step setup: from rules to first control

To avoid receivables control becoming scattered reminders, start with rules. The system works well when agreements are embedded: what counts as overdue, who reacts, and which actions are allowed.

1) Lock rules before settings

Collect key contract conditions and practical habits: payment terms, grace periods, partial payments, penalties, shipment conditions when debt exists. Often contracts say one thing while sales “by habit” do another — it’s best to surface that immediately.

Agree a simple model of responsibilities and statuses so there’s no dispute about “this is still okay” or “it must be blocked already.” Example: sales are responsible for client contact, accounting for recording receipts, and financial control for exception decisions.

Typical working sequence that gives quick results:

• consolidate payment and shipment rules into a 1–2 page document without legal detail
• approve debt statuses and the owner for each status (who acts first)
• set reminders and escalations by thresholds (for example, 3 days before due, on due date, +7 days overdue)
• define shipment limits: by amount, by overdue days or by client credit limit
• choose 3–5 reports and fix a cadence for review (daily/weekly) and owners

2) Run a short pilot

Before scaling, pilot with a small group of clients or one division. This uncovers typical gaps: payments exist but aren’t allocated; partial payments break status; sales bypass a block by verbal agreement.

A short practical training of 30–40 minutes by scenarios works best. For example: a client paid 30% of an invoice, requests a new shipment, and the remaining balance is already near its due date. The team must consistently know which status will appear, who approves exceptions, and which comments are mandatory.

If after the first week manual clarifications drop and overdues close faster, the basic rules are correct and you can broaden coverage.

Practical example: partial payment and the risk of a new shipment

A company ships equipment to a regular client. The client has three invoices: the first is 50% paid, the second is due tomorrow, and the third is disputed (the client claims part of the goods were defective) and is on hold. Meanwhile the salesperson scheduled a new shipment for the week. Without system control the risk is a new shipment while money for previous deliveries remains unpaid.

To make the situation clear, each document gets a status that reflects reality, not “the client is generally good.” The first invoice is marked “partially paid” with the outstanding balance and the next payment date. The second is “to pay (due tomorrow)”. The third is “disputed” or “under review” so it doesn’t mix with normal overdue items and goes into separate control.

Then the system sends reminders per rules. One day before due it notifies the client (if that’s the practice) and the responsible salesperson. On the due day, if unpaid, accounting is involved. For the disputed invoice a reminder goes to the claim owner (e.g., the salesperson and head of sales) rather than the payer, so communication and deadlines aren’t lost.

The shipment limit triggers based on open debt and “red” statuses. The new shipment is blocked because of the remaining balance and an active dispute. An exception is possible only by approval: for example, the CFO grants temporary permission for a limited amount or only with prepayment.

That same day the risk is visible in reports: debt age, list of disputed invoices, limit breaches and planned shipments for clients with blocks. Actions for today:

• call the client and record a repayment schedule for the first invoice
• confirm payment for the second invoice by end of day and set a control date
• assign an owner and a deadline (e.g., 48 hours) for the disputed invoice
• decide about the new shipment: prepayment, reduce amount, or approved exception
• update statuses so reports show the real picture

Common mistakes and pitfalls in implementing control

A frequent problem is that rules seem configured but people don’t understand statuses, who does what, and when to react. The system then becomes a set of notifications and reports that don’t change behavior.

Mixing statuses and reasons

When one field tries to cover different meanings, the system stops helping. “Overdue” and “dispute” are not the same. Overdue indicates timing, dispute indicates a situation and causes. If you mix them you won’t know whether to call and demand payment or to pass it to a document review.

Good practice: status answers “what is the debt now?” and a reason (or tag) answers “why did this happen?” Then reports won’t mislead and escalations become clearer.

Shipment limits without an owner

Limits are often set but nobody is assigned to approve exceptions. Salespeople then make ad-hoc agreements, and finance learns about it after the fact.

Check two things:

• who can temporarily lift a block and for how long
• where the exception reason is recorded (comment, approver, date)

Reminders without thresholds

If reminders go to everyone too often they will be ignored. Also bad is when notifications don’t distinguish situations: a client paid partially but receives a stern message as if the full amount is overdue.

Set thresholds and logic: a soft reminder 3 days before due, a repeat on the due date, escalation only on real overdue and only to the responsible person.

No payment reconciliation

Classic trap: payments exist, but the system still shows debt. Reasons are simple: payment arrived without invoice number, partial payment not allocated, advance not matched, or bank feed delayed. The result: statuses show “debt,” blocks trigger, and client relations suffer.

You need a ritual: daily reconciliation of receipts and quick resolution of “unidentified” payments.

Reports exist but nobody checks them

Perfect reports are useless without a schedule. When review is “ad hoc,” control becomes reactive.

A simple rule helps: record who and when views key reports (for example every morning) and what action follows the numbers: who to call, who to email, who to block shipments, who to clarify payments.

Short checklist and next steps

When control is configured, avoid getting lost in detail. Below are two cadences: a 10-minute daily routine and a 30–60 minute weekly review. They help keep money under control and prevent shipment surprises.

10-minute checklist (daily)

These checks are best done at the same time each day, e.g., at the start of the day:

• overdue: who became overdue today and who is increasing fastest
• large amounts: top-5 debtors by amount and their status (payment, promise, dispute)
• new shipments at risk: are there invoices for shipment to clients who are overdue or near limits
• yesterday’s receipts: what arrived, what didn’t, and which promised payments failed
• next 3 days: which payments are due soon so shipments aren’t blocked

Weekly checklist (once a week)

Weekly review should check rules as well as facts:

• limits: who to raise or lower, where the limit doesn’t match payment discipline
• exceptions: who ships around rules and why (temporary fix or ongoing practice)
• disputed cases: debts in dispute, shortages, returns, acts — to avoid technical overdue
• receipts plan: a 1–2 week forecast with payment probability
• root causes: why overdues occur (contract error, wrong due date, missing documents, approval failure)

To make checks accurate, first clean the data. Priority: counterparty cards (TIN/BIN, owners, contacts), contracts and attachments (payment terms, limit, currency), invoice due dates and closing documents. A common issue is different due dates in contract and invoice, which makes the system show the wrong overdue.

Lock the process in a one-page regulation: who changes statuses (and on what basis), who confirms exceptions, who can raise limits, and response times for overdue (for example, 1 day to make first contact, 3 days to escalate). Appoint one process owner in finance plus a backup.

Next step — check whether the infrastructure supports reliable system and reports: stability, backups, user access, and report generation speed. If current PCs or servers can’t handle the load, or you plan growth, consider upgrading workstations, servers, and integration support. In these tasks GSE.kz as a manufacturer and system integrator can help: financial control mustn’t depend on random failures.