Design an Invoice & Billing System

Problem statement

Design an invoice and billing system for a large e-commerce platform. After every checkout the system must generate an itemized invoice containing line items, taxes, shipping fees, and discounts, render a durable PDF or digital format for customer and accounting reference, handle partial or split payments, and store records for the legally required retention period. For business customers it must integrate with AP/AR workflows so that purchases land in the buyer's accounting system and the seller's receivables ledger.

The brief deliberately calls out four capabilities: itemized invoice generation post-checkout, taxes plus shipping plus discounts, PDF or digital format, and partial or split payments. Each one must appear explicitly in the design.

Why this problem is harder than it looks

Most candidates treat an invoice as a formatted email attachment. In reality an invoice is a financial and often legal document. Five properties make the design distinctive:

1. Money correctness. Totals must reconcile exactly: the sum of line amounts, discounts, taxes, and shipping equals the amount charged, the amount recorded in the ledger, and the amount collected from the payment gateway. A one-cent rounding mismatch between the cart, the invoice, and the ledger is a reconciliation break that finance teams investigate for hours.

1. Immutability. Once issued, an invoice cannot be silently edited. Corrections happen through credit notes or replacement invoices, both of which reference the original. Many jurisdictions mandate sequential, gap-free invoice numbering, which turns numbering into a distributed systems problem.

1. Tax jurisdiction complexity. A single order can span state, county, city, and special-district tax authorities. Sales tax in the United States alone has more than 13,000 jurisdictions, and the European Union runs VAT with country-specific rates, reverse-charge rules for B2B, and emerging real-time e-invoicing mandates. Tax must be computed against the rules in force at the time of supply and preserved as a snapshot on the invoice.

1. Payment lifecycle separation. An invoice is a claim for money; a payment is the settlement of that claim. Partial payments, split payments across methods, refunds, chargebacks, and write-offs mean the invoice carries a balance that evolves over weeks while the document itself never changes.

1. Compliance retention. Tax authorities in many countries require invoice records for 6 to 10 years. GDPR-style privacy regimes conflict with that retention duty, so the design must encode retention classes, not a single TTL.

The four planes of the system

A strong answer separates the architecture into four planes:

• Transaction plane: the checkout event that triggers invoicing, the order data it carries, and the guarantee that every paid order produces exactly one invoice.
• Financial plane: the double-entry ledger postings, accounts receivable balance, payment allocation, credit notes, and reconciliation with gateway settlement files.
• Compliance plane: tax calculation and snapshotting, sequential numbering, e-invoicing mandates, audit trails, and retention policy.
• Delivery plane: PDF rendering, storage, download links, email dispatch, and webhooks into the merchant's ERP or accounting stack.

The cloud can delay a PDF; it cannot delay correctness. The ledger and the invoice totals must be right at commit time, even if rendering and email are eventually consistent background work.