Track Client Balances in a Pooled Rep Payee Bank

Managing Social Security funds as a Representative Payee creates an accounting pattern that fits neither a standard AR nor a standard AP workflow. You receive one pooled bank deposit that belongs to many clients individually, then disburse room and board, personal needs, and other approved expenses from that same account. Every line must reconcile through the bank feed, and each client needs a running balance you can turn into a statement.

The good news is that NetSuite can handle this with native transactions. You do not need a separate GL account per client, and you do not need to force the process into a credit memo and refund model that misrepresents what is actually happening.

Why the Credit Memo and Refund Model Is Wrong for This

One consultant suggested eliminating the Vendor entirely and running everything through Customer Invoice, Client Deposit, Credit Memo, and Client Refund. That model treats each disbursement as if you were refunding an overpayment. Your clients do not owe you money in the traditional AR sense, and a credit memo is not the right instrument for paying a landlord on a client's behalf.

From an audit perspective, the credit memo and refund path muddies the trail. A reviewer sees "credit memo" and assumes a pricing correction or a returned sale. What you actually did was pay an expense out of funds you hold in trust. The transaction type should say what happened.

The Linked Customer and Vendor Model

The cleaner native approach is to keep each client as a single entity linked as both a Customer and a Vendor. NetSuite supports this on one record through the Other Relationships subtab, so you are not maintaining two separate profiles for the same person. Open the record and click the + icon on that subtab to add the other entity type.

• Deposits come in on the Customer side. A Social Security payment is recorded as a Customer Deposit against that client's record.
• Expenses go out on the Vendor side. You create a Vendor Bill (or write a check) naming the client as payee, with the expense line mapped to the appropriate expense account.
• Billable vendor bills create a Customer Invoice that draws down the client's deposit balance.

This keeps the money in one place while the transaction types stay honest about what each movement represents. The SuiteScript Records Guide documents the internal record structure for both customer and vendor records if you need to verify field behavior.

The deposit balance field does the heavy lifting

Each Customer record carries a Deposit Balance field (depositbalance). When you record a Customer Deposit, that balance increases. When you apply the deposit against an invoice, the balance decreases. This is the closest native equivalent to the "savings account per recipient" model, and it gives you a live per-client balance without creating a GL account for every person.

To see it, open the Customer record and check the Financial subtab. The Deposit Balance field updates as you post deposits and apply them.

Recording the Social Security Deposit

Go to Transactions > Customers > Accept Customer Payment, or use the dedicated Customer Deposit record at Transactions > Customers > Customer Deposit. On the deposit form:

1. Set the Customer field to the client.
2. Set the Account field to your pooled rep payee bank account.
3. Enter the amount of the Social Security payment.
4. Save.

The Customer Deposit is recorded in the GL as a liability (a customer prepayment) until it is applied against an invoice. That liability treatment is exactly right for funds you hold on behalf of someone else. The money is not your revenue; it is a balance you manage.

Recording the Expense Payment

For a disbursement such as rent or personal needs, you have two clean options.

Option A: Write a check directly to the expense. Go to Transactions > Bank > Write Checks. Set the payee to the client, select the pooled bank account at the top, and on the Expenses subtab enter the expense account (for example, a Room and Board expense account) and the amount. Because the client is set up as a Vendor, the payee resolves without a separate vendor record.

Option B: Create a Vendor Bill, then pay it. Go to Transactions > Payables > Enter Bills, select the client as the Vendor, enter the expense line, and save. If the bill is marked Billable, you can convert it to a Customer Invoice and apply the client's deposit balance to it, which reduces the running balance in one visible step. Then record the payment from the pooled bank account.

The billable-bill-to-invoice path is what ties the expense back to the client's deposit balance and produces the statement detail you need.

Producing a Client Ledger and Monthly Statement

Your goal is a statement showing beginning balance, deposits, expenses, and a running balance for each client. The Customer Deposit Balance gives you the current total, but a statement needs the detail behind it.

The cleanest route is a Saved Search on the Transaction record. Build it like this:

• Type: Transaction
• Transaction Type: Customer Deposit, Invoice, and Deposit Application
• Criteria: Customer is [client], Date is within the current month
• Results columns: Date, Transaction Type, Memo, Debit, Credit, and Running Total

The Running Total column gives you the running balance line by line, which is exactly what a monthly statement needs. Filter by the client and the posting period to produce the report for that person.

If you want a single report covering all clients, add Customer as a results column and group by it, then export to CSV. That gives your accounting team a working file, and you can format it into the statement you send each beneficiary.

Reconciling the Pooled Bank Account

Because every deposit and every check posts to the same bank account, the bank feed reconciliation works normally. Go to Transactions > Bank > Reconcile Bank Statement, select the pooled account, and match the Customer Deposits and checks against the bank statement lines.

This is where the audit trail pays off. Each reconciled line points back to a specific client and a specific transaction type. The monthly reconciliation also catches timing differences early, which matters when you are handling other people's money.

What to Avoid

• A separate GL account per client. Your client count changes over time, and the Chart of Accounts stays cleaner without it. Track balances on the Customer records instead.
• The Opening Balance fields for historical balances. Those fields simply generate a journal entry under the hood. If you are loading historical rep payee balances, you get more control by importing the opening transactions directly through AR or AP imports so they feed aging and the client detail naturally.
• Credit memos and refunds for expense payments. They misclassify the transaction and confuse anyone reviewing the subledger.

The Control That Keeps It Clean

The control here is that every movement of client funds flows through a transaction type that names what actually happened. Deposits increase the Customer Deposit Balance. Billable vendor bills convert to invoices that draw that balance down. Checks and ACH payments clear through the pooled bank account and reconcile against the feed. Nothing touches a GL account that does not belong to the pooled bank or a legitimate expense bucket.

That structure keeps your records audit-ready for SSA reviews and lets you close the books without untangling a web of credit memos. The SuiteTalk SOAP Web Services Records Guide covers the same customer and vendor record relationships if your team works through the API layer instead of the UI.

Test the linked Customer and Vendor setup with one client first, confirm the statement output matches your SSA reporting needs, then roll it out across the rest of your caseload.