Payments Received
Record customer payments against invoices, share branded payment links, and reconcile partial payments with a live history and real-time Amount Remaining.
Payments Received is how you record money coming in against an outstanding invoice. Muin tracks each payment as its own transaction — not a single “paid/unpaid” flag — so partial payments, mixed methods, and multi-date installments all stay correct without spreadsheets on the side.
If Invoices is where you bill and AR Aging is where you chase, Payments Received is where the money actually lands and the Amount Remaining reconciles itself.
How a Payment Gets Recorded
Invoice Sent → Payment Link / Manual Entry → PaymentTransaction Row →
Amount Paid Updates → Status Advances → Payment History Panel| Entry Point | What It Does |
|---|---|
| Pay Now button on invoice detail | Creates a branded public payment link the customer can pay online |
| Mark Invoice as Paid modal | Records an offline payment — check, ACH, wire, cash — with a payment date and method |
| Request Payment modal | Sends a payment-request email or link to a recipient with an optional message |
| Automatic link on invoice send | Invoices that are sent to a customer get a reusable payment link attached |
Every completed payment — whether it came through a link or was entered manually — becomes a PaymentTransaction row. That row is the authoritative source for the invoice’s Amount Paid, Amount Remaining, and payment status. Nothing about the balance is stored as a memo on the invoice.
Recording an Offline Payment
Open the invoice from Finance > Invoices and click Mark as Paid in the header. The modal asks for two fields:
| Field | What It Means |
|---|---|
| Payment date | The date you actually received the money — not today’s date if a check cleared yesterday |
| Payment method | A short free-text note like Check #1234, ACH transfer, Wire, Cash, or Manual — Stripe batch |
Click Mark as Paid to persist. The invoice status flips to Paid, the paid_at timestamp is set, and a payment row is created so the history panel stays in sync with the status.
The payment method field accepts anything — it is the free-text reference the accountant will read when reconciling against the bank. Keep it short and specific. Check is less useful than Check #1234, dated Mar 14.
Sharing a Branded Payment Link
Click Pay Now on an invoice to generate a public payment link. The link opens Muin’s hosted payment page, pre-filled with the invoice amount, customer name, and branded with your tenant. The URL is single-tenant and expires on a schedule (30 days by default).
When a customer completes a payment through the link, the PaymentTransaction is created automatically through the platform payments pipeline and flows back into the invoice just like a manual entry would. The flow is identical from the invoice’s perspective — the Amount Remaining reconciles regardless of whether the money came in manually or through the link.
Invoices that are sent to a customer through Muin’s send flow also get a payment link created and stored on the invoice record, so the customer can click through from the invoice email directly. You do not need to press Pay Now again for invoices that already have an active link.
The banner at the top of the detail page tells you the link’s status at a glance:
| Status | What It Means |
|---|---|
| Active | The link is valid, not used, and not expired — share it confidently |
| Used | A payment was completed through this link — no further action needed |
| Expired | The link’s expiry date has passed — click Pay Now to mint a fresh one |
The Payment History Panel
The Payment History panel on every invoice detail page is the authoritative log of payments against that invoice. It is powered by GET /api/v1/finance/invoices/{id}/payments — which queries real PaymentTransaction rows, not a summary stored on the invoice.
Each row shows:
| Column | What It Shows |
|---|---|
| Amount | The amount actually received (can be less than the invoice total for partial payments) |
| Status | succeeded, completed, paid, failed, cancelled, pending, or processing — colored by outcome |
| Method | The method string — card, bank, check #1234, ACH, etc. — plus any captured detail (last-four, institution) |
| When | Processed date if set, otherwise the created date |
| Payer | Payer name or email when the payment came in through a branded link; blank for manual entries where the operator did not supply a payer |
Empty states show a neutral “No payments yet” message — important on brand-new invoices, where zero history is the correct picture.
Amount Remaining Reconciliation
The summary panel on the invoice shows four values that always agree:
| Value | How It Is Computed |
|---|---|
| Total Amount | subtotal + tax − discount, fixed when the invoice is issued |
| Amount Paid | Sum of successful PaymentTransactions linked to this invoice |
| Amount Remaining | Total Amount − Amount Paid — computed on read, not stored |
| Payment Status | paid if fully paid, partial_paid if some has been received, else sent / viewed / overdue |
Because Amount Remaining is derived from the payment transactions, it reconciles itself automatically:
- Record a partial payment for $300 against a $1,000 invoice → Amount Paid becomes $300, Amount Remaining becomes $700, status flips to Partial Paid.
- Record a second payment for $700 → Amount Paid becomes $1,000, Amount Remaining becomes $0, status flips to Paid and
paid_atis set. - If the customer overpays (rare but possible) → the history row stands on its own; a refund or adjusting transaction is the correction path.
You never edit Amount Paid directly. The balance comes from the transactions.
Partial Payments
Partial payments are a first-class flow. A customer paying $300 against a $1,000 invoice is not an error or an edge case — it is the normal AR rhythm.
When a partial payment is recorded:
- The invoice’s status transitions to Partial Paid
- Amount Remaining reflects the new balance
- AR Aging continues to track the invoice for reminder eligibility, because statuses
sent,viewed,partial_paid, andoverdueare all eligible for the reminder ladder - Each partial receipt appears as its own row in Payment History
You can keep adding payments to the same invoice as they come in. The last payment that brings amount_paid >= total_amount is the one that flips the invoice to Paid.
How Payments Connect to Other Surfaces
| Surface | What It Does With Payment Data |
|---|---|
| Invoices list | Shows status badges (Sent / Partial Paid / Paid / Overdue) computed from payment totals |
| AR Aging | Eligible invoices are those still showing a balance — fully paid invoices drop off the ladder automatically |
| Cash Flow | Received payments feed the cash-in side of the forecast |
| Customer detail (Person) | Payment history rolls up to give a per-customer view of what has come in across all their invoices |
| Reconciliation | PaymentTransaction rows are the source-of-truth side when matching against bank feed transactions |
There is no separate Payments Received list page — the log for any given invoice lives on that invoice’s detail view. A global list is on the roadmap as a dedicated /finance/payments-received page and is marked Coming Soon in the navigation until then. In the meantime, the Invoices list filtered to Paid and Partial Paid gives you the same information, scoped by status.
Good Practice
- Record payments the day you receive them. The payment date field exists for a reason — back-date accurately so cash flow and reconciliation stay honest.
- Use specific payment method strings.
Check #1234is worth five timesCheckwhen an accountant is reconciling against the bank statement six weeks later. - Let the link do the heavy lifting. When a customer pays online, the PaymentTransaction is created by the payment pipeline — no double-entry needed. Mark as Paid is only for offline receipts.
- Watch the status, not the link. A payment link that says Used is a signal the payment went through; let the transaction row and the Paid status confirm it.
- Partial payments are fine. Don’t split invoices just to record partial receipts — the same invoice can accumulate as many payment rows as it needs.
Common Issues
| Issue | Cause | Solution |
|---|---|---|
| Invoice shows Paid but Amount Remaining is positive | Rare — a failed PaymentTransaction was counted but later reversed | Refresh the page; the balance is computed live from current transactions |
| Mark as Paid modal will not submit | Payment method field is empty | Enter any short method string — it is required because a blank method is useless for reconciliation |
| Pay Now says “Failed to create payment link” | Payments integration is not configured or the tenant is not payment-enabled | Check Payments settings; the toast message is the exact error for support |
| Payment went through the link but Amount Paid did not update | Transaction is still in pending or processing status | Only successful transactions count toward Amount Paid — wait for the processor to finalize |
| Payment History row shows a payer email but no name | Customer paid as a guest and only supplied an email | Expected behavior for anonymous link payments; the email is the identifier |
| Recording a second payment after fully paid | Customer overpaid or you’re recording a duplicate | If overpayment, leave it and issue a refund through the payments module; if duplicate, open support — the fix is to void the duplicate transaction, not edit the invoice |
Related Features
- Invoices — Where you create and send the invoices that payments land against
- AR Aging and Collections — The reminder ladder for invoices with an outstanding balance
- Cash Flow — Payments received feed the inflow side of the forecast
- Bills — The payables-side counterpart, where Muin tracks what you owe vendors
Need Help?
If a payment is not reflecting on the invoice:
- Open the invoice detail page and scroll to Payment History — the row is either there or it isn’t
- If the row is there with status
succeededbut Amount Remaining hasn’t updated, reload the page; the balance is computed from transactions on each read - If the row is missing entirely, confirm the payment was completed on the customer’s end (link status should read Used or the check should have cleared)
- For offline payments, double-check that you submitted the Mark as Paid modal — an open modal without submit does not record anything
- Contact support through the in-app help widget with the invoice number and the payment method / date — both are in the audit trail