A Customer Payment Tracker That Shows Who Owes You, and for How Long

A customer payment tracker has to answer two questions at a glance: how much each customer owes you, and how long it has been owed. A spreadsheet handles the first well. It fails at the second the moment a customer pays part of what they owe, because then you have to decide which bill the payment cleared, and nobody does that consistently by hand.

This is how the Trade Ledger in the AtlasLinq dashboard tracks both, set up step by step. It is part of Enterprise, and the Enterprise Admin and any Manager can use it. It is a running balance for the people you trade with, not accounting software, and the end of this post says where that line is.

Why the spreadsheet stops working

Picture a distributor you supply every week. They owe for three deliveries, then pay a round amount that covers one and a half of them. In a spreadsheet you now have to decide which delivery is still open, edit two rows, and hope whoever updates it next week does it the same way. Most people stop allocating and keep one total, and the total cannot tell you that some of that money is three months late.

The ledger never asks you to allocate. You record what you gave and what you got, and it works out the rest: a payment clears the oldest amount still owed first. Nothing about that is stored, it is recalculated from your entries every time, so an edited or deleted entry can never leave the totals out of step.

Step 1: Add the people you trade with

Open Ledger in the dashboard and add each customer or supplier under Parties. If someone already left their details on one of your team's cards, start typing their name, company or phone number and the ledger fills it in from your leads, so a customer you met at a trade show does not have to be typed in twice. Only the name, company and phone number are copied across; their notes and lead status stay where they were.

Step 2: Record what you gave and what you got

The quick-add bar at the top is built for the moment a delivery leaves or a payment arrives. Pick the party, type the amount, and choose You Gave for goods or credit that went out, or You Got for money that came in. Add a due date whenever there is one. It is optional, but an amount with no due date can never be overdue, so it never shows up where you look for late payers.

Step 3: Use orders if you sell against them

If customers place orders that you deliver in parts, create the order under Orders with its lines. Orders are numbered automatically (ORD-1, ORD-2, with a prefix you can change), and each delivery records what actually went out, so the order always shows what is still to deliver.

Payments can be tagged to an order. A tagged payment pays that order first, and anything left over stays with the order as an advance until the goods are delivered. If the order is cancelled, the unused advance becomes general credit for that customer rather than vanishing. Untagged payments keep following the oldest-first rule, so a ledger with no orders behaves exactly as it did before.

Step 4: Read who is late, and by how much

Every unpaid amount sits in one of six ages, from due this week to more than sixty days overdue, and the summary at the top shows how much is in each. That one strip is what a spreadsheet total hides.

Each party also gets a short rating: Pays on time, Watch, or Not enough history. It is calculated only from how they have paid you, never from their name or location, and it says so: it is your own record, not something the customer confirmed. Amounts without a due date are left out of it, rather than counted as paid on time.

Step 5: Send a statement on WhatsApp

From a party's panel you can send their statement on WhatsApp. It opens WhatsApp on your own phone or computer with the message already written, and you read it and press send yourself. Nothing goes through AtlasLinq's servers, and the message is a statement of the account rather than a demand, which is usually the tone that gets an account settled without souring the next order.

Where the ledger lives, and backing it up

The ledger is stored in the browser you use for the dashboard, one ledger per organization, which keeps it fast. The flip side is that it stays in that browser. Export it as a JSON file regularly: that is your backup, and importing it is how you move the ledger to another computer. The separate CSV exports for parties, entries and orders open in any spreadsheet.

The parties and entries files are also what AtlasLinq Anchor reads, once it is out, to answer questions such as which accounts are past sixty days or how much a customer has been billed against what they paid. It is coming soon; analyzing sales data without uploading it explains the approach.

When you need something else

The ledger is a running balance, the way a shopkeeper's credit book is. It does not raise tax invoices, file returns or keep a full set of accounts, and it is not meant to. If you need bill-wise accounting for tax, keep your accounting software and use the ledger for what it is good at: knowing, before you ship the next order, who owes you and for how long.