B2B Net Terms & Payment Terms (30/60/90 Days)

Paid pluginsize Mplanned, not built

Indicative price, not an offer: $25-75/mo + fraud scoring fees

Generated from docs/plan/paid/b2b-net-terms-payment-terms/PLAN.md in the AstroBaaS repository. Nothing described below is implemented — it is the written plan for it.

Wholesale customers demand Net-30/60/90 payment terms instead of upfront payment. This paid module enables deferred payment workflows with credit limits, invoice aging, and dunning automation.

The problem

Wholesale buyers expect ‘net 30’ or ‘net 60’ invoicing; I can’t extend credit without losing the sale. I need to track who owes me and automate collection when invoices age.

What it does

• Payment term choices at checkout: ‘immediate’, ‘net_30’, ‘net_60’, ‘net_90’, ‘deposit_50’, ‘deposit_25’
• Customer credit limit: set per customer (admin), prevent checkout if order + current balance exceeds limit
• Invoice generation: formal tax invoice with due date, terms, payment instructions, item breakdown
• Partial payments: accept and track partial payments against an invoice; don’t mark paid until full amount received
• Aging report: 0–30 days, 30–60, 60+ overdue with totals by customer
• Dunning automation: send reminders at +5 days, +15 days, +30 days overdue; optional escalation (stop shipments, charge late fees)
• Payment recording: admin manually records a payment (check received, wire transfer) and associates with invoice
• Deferred revenue: report shows cash received vs. invoiced (accrual accounting support)

What it deliberately does NOT do

Each boundary carries its reason. A boundary without a reason gets crossed by the next person who reads this.

• Accounts receivable integration (SAP, NetSuite) — merchants export CSV; integration is per-installation.
• Credit scoring — merchants decide limits manually based on business relationship.
• Late fees — merchant policy; module can apply if configured, but no default calculations.

Data model

Same as b2b-payment-terms-deposits (combines both features). Add to Order: payment_terms enum, due_date, invoice_number. Add to Customer: credit_limit_cents, credit_used_cents. Add Payment Ledger: { order_id, amount_cents, received_date, method, reference }.

API

• Same as b2b-payment-terms-deposits plus:
• GET /api/reports/deferred-revenue — accrual report: invoiced vs. cash received by month

Every route added here must also appear in src/pages/openapi.json.ts — a test fails the build if it does not.

Admin

Same as b2b-payment-terms-deposits. ‘B2B Payment Terms’ panel shows credit limits, aging, and dunning queue.

The seam — why this is paid

Same as b2b-payment-terms-deposits.

Paid module owns deferred payment processing, credit risk scoring, dunning automation, and legal terms templates per region; core only tracks invoice state

Dependencies

• structured-address-model
• payment-status-tracking

Acceptance checks

Each of these must be able to fail. Before claiming this is done, break the code deliberately and watch each one go red.

• Customer has €10,000 net-60 credit limit; places €8,000 order; order placed with due_date = +60 days
• Same customer tries to place €3,000 order; rejected (€8,000 + €3,000 exceeds €10,000 limit)
• Invoice generated with due date 60 days out; sent to customer
• Customer pays €5,000 on day 40; balance remaining €3,000; invoice not marked paid
• Customer pays €3,000 on day 50; invoice marked fully paid; payment_status=‘paid’
• Aging report shows: ‘0–30 days: €2,000 (2 invoices)’, ‘30–60: €5,000 (1 invoice)’, ‘60+: €0’
• Invoice exceeds 30 days overdue; dunning reminder sent automatically; audit logged

Risks

Same as b2b-payment-terms-deposits.

Commercial context

The anchor is what the nearest equivalent charges on Shopify or Magento today. It is context for a pricing decision, not the decision.

---

Generated from the commerce plan. See docs/COMMERCE-PLAN.md for the full catalogue and ../../AI-GUIDE.md for how to work on this repository.