# Invoice System From the first line item to the payment receipt: an owned invoicing workspace with clear balances, customer PDFs and Stripe and PayPal checkout integrations. - Role: Product and workflow design, system architecture, AI-assisted implementation and operational verification. - Status: In operation / scoped payments - Status code: in-operation-scoped-payments - Case page: https://oleksii.almalvs.online/work/invoice-system - Reviewed: 2026-10-04 ## Problem A finished job still leaves administrative work: rebuild the scope in an invoice, send a document, find the right payment link and work out what is still owed. When these steps live in separate tools, the same information gets entered again and the next action becomes harder to see. ## Constraints - Keep drafts editable and released documents traceable - Separate an invoice, a delivery event and a confirmed payment - Offer payments only where the provider and invoice are configured ## Architecture - Customer and line items - Review and release - Invoice PDF and customer portal - Provider checkout and settlement - Updated balance and receipt ## Decisions - Keep the staff workspace and customer portal separate - Derive payment labels from the outstanding balance and due date - Record provider events before reconciling a payment - Keep archive reversible without rewriting financial history ## Evidence - Invoice editing, PDF release, portal views and balance-based status labels are implemented - Provenance: First-hand account. Published from Oleksii Mazur's first-hand account. - Sources: None published. - Stripe sandbox checkout and signed-webhook settlement were verified; scoped live checkout was also opened and resumed - Provenance: First-hand account. Published from Oleksii Mazur's first-hand account. - Sources: None published. - PayPal live settlement and a generated receipt are recorded in operational evidence - Provenance: First-hand account. Published from Oleksii Mazur's first-hand account. - Sources: None published. - One authorized receipt email has confirmed provider delivery; future automatic receipt delivery was enabled with its first post-activation payment still pending in the reviewed record - Provenance: First-hand account. Published from Oleksii Mazur's first-hand account. - Sources: None published. ## Safety and boundaries - Screenshots use only fictional local fixtures; they do not show customer records or prove provider delivery - Payment evidence is dated September 29 to October 3, 2026; provider account status and invoice eligibility can change - A completed live Stripe settlement is not established by the reviewed evidence - Owning the application still requires hosting, maintenance and payment-provider services; no fee, savings or compliance claim is made ## Stack - React - TypeScript - Node.js - PostgreSQL - PDF documents - S3-compatible storage - Stripe Checkout - PayPal Orders - Resend ## Media ![Actual Invoice workspace showing fictional customers and Draft, Unpaid, Partially paid, Paid and Overdue labels.](https://oleksii.almalvs.online/images/evidence/invoice-workspace.png) Actual Invoice interface captured locally on October 4, 2026, using fictional customers and amounts. Local API fixtures demonstrate the status labels; this is not a production financial dashboard. ## Credits - None published. ## Public sources - None published. ## Related projects - [field-operations](https://oleksii.almalvs.online/work/field-operations) - [smart-lead-system](https://oleksii.almalvs.online/work/smart-lead-system) ## One place to follow the invoice Canonical case section: [https://oleksii.almalvs.online/work/invoice-system#result](https://oleksii.almalvs.online/work/invoice-system#result) Invoice connects the commercial steps after a job: prepare the bill, review the details, release a numbered document, give the customer access and follow the remaining balance. The staff workspace and customer portal serve different needs, while the invoice remains the common record. This is a standalone application with its own source, configuration and database boundary. Provenance: First-hand account. Published from Oleksii Mazur's first-hand account. Sources: - None published. ## Build, review and release Canonical case section: [https://oleksii.almalvs.online/work/invoice-system#workflow](https://oleksii.almalvs.online/work/invoice-system#workflow) Start with the customer, service address and itemized work. Each line has a description, quantity and rate; the editor calculates the subtotal as you work. Review tax, discount, due date and the receipt preference before release. Release produces a numbered invoice and a PDF tied to that version. Delivery is an explicit staff action. The customer portal presents the released items, amount due and available documents. ![Actual Invoice editor with fictional Juniper Studio details, three service line items and a calculated total.](https://oleksii.almalvs.online/images/evidence/invoice-editor.png) Actual Invoice application rendered locally, October 4, 2026. Fictional customer, services and amounts supplied by a local fixture. No invoice was saved, released or sent. Provenance: First-hand account. Published from Oleksii Mazur's first-hand account. Sources: - None published. ## Know what needs attention Canonical case section: [https://oleksii.almalvs.online/work/invoice-system#statuses](https://oleksii.almalvs.online/work/invoice-system#statuses) Draft means the invoice is still being prepared. Released invoices show Unpaid, Partially paid or Paid from the outstanding balance. An unpaid remainder past its due date becomes Overdue, including a partially paid invoice. A Released fallback is used when the balance is unavailable. Archive removes an invoice from the active staff view and can be reversed; it does not erase financial history or invalidate customer links. Delivery and receipt-generation states remain separate from payment status. Provenance: First-hand account. Published from Oleksii Mazur's first-hand account. Sources: - None published. ## Stripe and PayPal, with evidence Canonical case section: [https://oleksii.almalvs.online/work/invoice-system#payments](https://oleksii.almalvs.online/work/invoice-system#payments) Both integrations are implemented and configured in the reviewed deployment. Stripe uses hosted Checkout; PayPal uses Orders checkout and capture. The portal can resume an open checkout or let the customer change provider after checking the previous attempt. Stripe sandbox payment and signed-webhook settlement were verified, and a scoped live checkout was opened and resumed. PayPal live settlement is recorded. These are different acceptance results: the evidence does not establish a completed live Stripe charge or unrestricted payment availability for every invoice. ![Actual customer invoice portal with a fictional invoice, line items and the Stripe and PayPal payment choices.](https://oleksii.almalvs.online/images/evidence/invoice-portal.png) Actual customer portal rendered locally with fictional data, October 4, 2026. Payment availability is simulated for this capture; no checkout or payment was initiated. Integration evidence is described below. Provenance: First-hand account. Published from Oleksii Mazur's first-hand account. Sources: - None published. ## Close the loop with a receipt Canonical case section: [https://oleksii.almalvs.online/work/invoice-system#receipts](https://oleksii.almalvs.online/work/invoice-system#receipts) Verified settlement updates the balance and supports a branded receipt PDF. Operational records confirm a generated receipt and one explicitly authorized receipt email with provider-confirmed delivery. Automatic receipts for future settlements were enabled on October 3, respecting the invoice's delivery preference and excluding historical payments. The first actual payment after that activation was still pending in the reviewed record. A generated PDF, an accepted email and a customer's reading of that email are separate events. Provenance: First-hand account. Published from Oleksii Mazur's first-hand account. Sources: - None published. ## Why own the workflow Canonical case section: [https://oleksii.almalvs.online/work/invoice-system#ownership](https://oleksii.almalvs.online/work/invoice-system#ownership) An owned system lets the business shape its invoice fields, document design, release steps and customer experience around the way it works. Its records and integration code can evolve together, and a future connection to field operations can use an explicit API instead of copying data between screens. That connection is an extension opportunity, not a claimed existing integration. Ownership also brings responsibility for hosting, backups, updates and support; Stripe and PayPal remain external services. Provenance: First-hand account. Published from Oleksii Mazur's first-hand account. Sources: - None published. ## The implementation behind the screens Canonical case section: [https://oleksii.almalvs.online/work/invoice-system#engineering](https://oleksii.almalvs.online/work/invoice-system#engineering) React and TypeScript power the staff and customer interfaces. Node.js services and PostgreSQL hold invoice versions, payment attempts and settlement records; PDF documents use S3-compatible object storage. Provider callbacks are verified and reconciled against the expected invoice, amount, currency and account. Durable records help avoid repeating a send or capture when a result is uncertain. These are implementation choices supported by source and targeted operational tests, rather than a claim of security certification. Provenance: First-hand account. Published from Oleksii Mazur's first-hand account. Sources: - None published.