Accounts Receivable, built on the same controls as your payables

• Aging lives in a spreadsheet that is correct on the day someone rebuilds it.
• A part-paid invoice gets edited in place, and the history of what was applied is gone.
• Nobody can say whether the customer with the biggest balance has actually been chased.
• The tax code on the customer record was typed by hand, so the invoice carries a name that does not match the registry.

A receivable is only as good as the identity behind it, so the customer master is built on the tax registry rather than on typing.

• MST lookup autofills legal name, address and taxpayer status from the tax registry (VietQR, GDT-sourced), cached and refreshed when it goes stale.
• The form is honest about what happened: invalid code, not found, registry unavailable with a retry, or resolved with the source shown.
• If the registry cannot resolve a code, enter the identity by hand. It saves, and it is clearly marked as not registry-verified rather than silently trusted.
• Payment terms, credit limit and credit hold live on the customer. A customer on hold cannot be issued a new invoice, and issuing checks the limit.
• The same lookup identifies vendors on the payable side, so one company is one identity.

An invoice has three real states and a small number of hard rules, which is what makes the rest of the module trustworthy.

• Draft, issued, cancelled. Nothing else is stored, and everything else is calculated.
• Line editor with quantity, unit price and VAT percent. Totals are computed on the server.
• The invoice number is yours. BancoOS records the number and code of the e-invoice you issued through your GDT provider, it does not invent one.
• Issuing checks a positive total, an active customer, a due date on or after the issue date (defaulted from the customer's terms), the credit limit and the accounting period.
• An invoice with live payments applied to it cannot be cancelled. Reverse them first.
• Filter by issue or due date range, status and customer. Export to CSV, XLSX or PDF.

Money arrives in shapes that do not match invoices, so the ledger is built for partials, splits and corrections from the start.

• Record a receipt with its bank reference and apply it oldest invoice first, or choose the invoices yourself.
• Partial payments, one receipt spread across several invoices, and money left on account are all normal cases, not workarounds.
• Allocations are append-and-reverse. Rows are never edited or deleted, so unapplying money leaves a trail instead of erasing one.
• The system will not over-apply. Applied amounts stay at or below both the receipt and the invoice, checked under a row lock before anything is written. A refused request writes nothing at all.
• Submit twice and you get the same receipt back, not two. A look-alike receipt is held for confirmation before it is accepted as a genuine second payment.
• A receipt dated into a closed period posts to the first day of the next open one.

Nothing about your position is stored as a snapshot, so there is no report to refresh and no overnight job to trust.

• Outstanding, paid state, overdue days and every aging bucket are calculated from the allocation ledger when you look at them. They cannot drift, and nothing has to run at midnight to make an invoice overdue.
• Aging on due date in the buckets your accountant expects: current, 0-30, 31-60, 61-90, 90+, per customer, with the oldest days overdue.
• The overview answers the questions you actually ask: what is outstanding, what is due this week, what is overdue, what came in over the last 30 days, and which customers are worst.
• A collections worklist of every overdue invoice with days overdue, balance, open follow-ups and when it was last touched.
• Log a call, email, note, promise to pay or escalation against an invoice, with a follow-up date, and close it when it is done.

Receivables inherits the platform controls your payables already run on, rather than introducing a second set.

• Row-level security on every receivable table. One tenant cannot see another's customers.
• Hash-chained audit on every material action: invoice created, updated, issued or cancelled, receipt recorded and applied, allocation reversed, collection logged, customer changed, report exported.
• Role gating: anyone reads, owner, admin or approver writes invoices, receipts, allocations and collections, owner or admin edits the customer master.
• Shared fiscal periods, so receivables and payables close on the same calendar.
• Full English and Vietnamese interface.

AR sits next to the connectors you already use. Customer identity is resolved against the tax registry, sales e-invoices are issued through your licensed GDT provider and recorded here with their number and code, and the operational ledger reconciles to MISA, Business Central or whichever system holds your books. Receipts carry the bank reference from your statement so the match is there when you need it.

How to issue and record GDT e-invoices in BancoOS

Every receivable table is protected by row-level security, so one tenant can never read another tenant's customers, invoices or receipts. Material actions are written to a hash-chained audit log that an auditor can replay in order, and roles decide who may write rather than who may see. Data is encrypted in transit and at rest, and receivables shares the fiscal calendar and permission model of the rest of the platform.

See the AR product page: features, plans and a live demo signup