Subscription Billing for a Japanese B2B SaaS Company
Designed and built a clickable billing platform for a Tokyo SaaS company that sells shift scheduling and attendance software to Japanese businesses: invoice runs by each customer's closing date, qualified invoices with tax rounded once per rate, bank transfer matching on half-width katakana payer names, and dunning by payment method.
Most of our work is under NDA. Per agreement, we can share the work but not the company details - all names and identifying information shown here have been changed.
Dashboard, invoice runs, run detail with the qualified invoice preview and approval, furikomi matching with its receipt match panel, and dunning with its case panel.
Virtual account, amount equal to an invoice, amount equal to a sum of invoices, learned payer name, kana name and short by a transfer fee, with deducted fees written off up to ¥880.
Each invoice groups its lines by tax rate and rounds the tax down once per rate, as the Qualified Invoice System expects, and prints the issuer's T + 13 digit registration number.
22 Japanese customers with 24 billing accounts on 6 closing days, 15 invoice runs, 15 open invoices, 14 bank receipts, 2 dunning policies, 12 dunning cases and 6 staff users.
Hoshizora Cloud billed from a spreadsheet copied out of Salesforce each month and a card-only billing tool. Around 70% of revenue arrived by bank transfer, so two people spent four days every month-end building invoices by hand, matching transfers by reading katakana payer names in the bank's portal and chasing customers who had deducted the transfer fee. Month-end close took 9 working days and the auditors flagged revenue timing twice.
Tsumugi runs billing the way Japanese B2B customers expect to be billed: one qualified invoice per billing account per closing date, checked before anything is sent and approved by someone other than the preparer, a virtual account per billing account so transfers match on their own, a matching screen for the rest, and dunning steps set by payment method.
Most of Hoshizora Cloud's 2,400 customers, from 20-person clinics to retail chains with 300 stores, pay by bank transfer against an invoice issued on their own closing date, and every one of those invoices has to meet the Qualified Invoice System.
Payer names arrive in half-width katakana with legal-form abbreviations such as カ), often without a reference, and customers deduct the transfer fee when their terms say they bear it. Finding the right invoice meant searching by amount and guessing at names.
Since October 2023 an invoice must show the issuer's registration number, the totals and consumption tax per rate and the recipient, with tax rounded once per rate rather than per line. Credits of ¥10,000 or more need a qualified return invoice.
Customers expect one invoice per closing date (締め日), commonly month-end or the 20th, with payment due on a set day such as the end of the next month and moved for bank holidays. Mid-month seat changes still have to be prorated the same way every time.
Annual prepayments were booked as revenue on the day they were invoiced instead of over the service period under ASBJ Statement No. 29, and the Electronic Books Maintenance Act requires issued invoices to be stored unchanged and searchable by date, amount and counterparty.
Mapped 6 user roles, 45 screens across staff, customer portal and public pages, and the data model for customers, billing accounts, versioned plans and prices, subscriptions, usage, invoice runs, invoices, credit notes, payments, dunning cases and revenue schedules. Wrote down the rules the design follows: the Qualified Invoice System and return invoices, consumption tax rates and rounding, closing dates and payment terms, virtual accounts and transfer fees, the Installment Sales Act and 3-D Secure, the Electronic Books Maintenance Act, ASBJ Statement No. 29 and the APPI.
Built 5 key screens on a production dashboard kit: the dashboard with MRR, ARR, churn and retention, MRR movements, A/R ageing by payment method and cash expected; invoice runs with a closing-date calendar and Build run; the run detail with pre-flight checks, the qualified invoice preview, exclude, rebuild and approve and issue; furikomi matching; and dunning with promises, pauses and service suspension. All actions run on local state.
Integration with a card gateway (such as Stripe, GMO Payment Gateway or PAY.JP), convenience-store payment, virtual accounts through a bank API or Zengin-format files, freee or Money Forward journals, Salesforce or kintone, the National Tax Agency registration check, Peppol (JP PINT), email delivery and a certified timestamp service. Staff roles with approval limits, an append-only audit log, documents kept for 10 years, and the remaining screens: customers, catalogue, quotes, subscriptions and proration, usage, credit notes, revenue, reports, settings, the customer portal and the public quote and pay pages.
Invoice runs are built per closing date, with the billing accounts closing on each one shown in a calendar strip. Pre-flight checks cover usage imports, pending changes, addresses, negative totals, the registration number, movements over 30% and missing PO numbers, and the preparer cannot approve their own run.
Any invoice in a run opens as the qualified invoice the customer will receive: 請求書, the addressee with 御中, the issuer block with its T number, closing and due date, virtual account payment details and the totals per tax rate.
Payer names are normalised from half-width katakana with legal-form prefixes removed, then candidate invoices are ranked with the rules that matched. The difference comes with its treatment: write off as transfer fee within ¥880, leave as short, hold an excess as credit, or refund. A name matched once is learned for next time.
Card and convenience-store customers get card retries on days 1, 3 and 7, a reminder email, a call task on day 10, a restriction notice on day 20 and suspension on day 30. Bank transfer customers skip the retries. A promise to pay or a pause moves the next step.

Designed and built a clickable merchant dashboard for a Mexican online payment gateway that takes cards with meses sin intereses, SPEI transfers and OXXO cash vouchers in MXN: every payment from authorisation to settlement, declines in plain language, refunds with approval limits, chargebacks sorted by deadline and payouts that break down to the last fee.

Designed and built a clickable spend-management platform for a Valencia fintech that gives Spanish SMEs company cards: budgets and card controls checked at authorisation, every transaction matched to its receipt, IVA marked recoverable or not from the invoice type, and a keyboard-driven review queue that turns card spend into bookable entries.
Enterprise Software Engineering - Human + AI
Contact Us
© 2026 - Copyright. All Rights reserved Oceanlab
Location
Global Headquarters
21 Merchant Road, 3rd Floor, Singapore 058267
Main corporate office and leadership operations
North America Office
548 Market Street, PMB 12345, San Francisco, CA 94104
Client operations and business development
India Office
402 Shivalik Shilp II, SG Highway, Ahmedabad 380015
Engineering and delivery center
Enterprise Software Engineering - Human + AI
Contact Us
Locations
Global Headquarters
21 Merchant Road, 3rd Floor, Singapore 058267
Main corporate office and leadership operations
North America Office
548 Market Street, PMB 12345, San Francisco, CA 94104
Client operations and business development
India Office
402 Shivalik Shilp II, SG Highway, Ahmedabad 380015
Engineering and delivery center
© 2026 - Copyright. All Rights reserved Oceanlab