会計・給与のコールドテスト — 請求書・仕訳・経費精算・給与・年末調整・書類DL
適格請求書、複式簿記の借方＝貸方バランス、経費精算の承認フロー、給与の支給控除グリッド、年末調整の還付/追徴ライブ計算、書類セルフサービスのダウンロード行。会計と給与の核心作法を6枚で踏破し、連載で最初の 5/5 を出した業界です。
会計・給与 の cold test、6 画面のまとめ。
なぜ会計・給与UIは難しいのか
会計と給与は「数字が合うこと」が常に前提です。仕訳の借方＝貸方バランスを強制し、複数税率（10%/8%軽減）の混在を税率別内訳で正しく見せ、経費精算では申請→承認→差戻しの流れと差戻しコメント必須を組み立て、給与の支給控除がライブ再計算される。会計事務所や経理部の人が違和感を持たない密度で組まないと、信用に直結します。連載で初めて 5/5 が出たのが #39 経費精算で、ここから「ほぼ戦わずに出荷できる」群青のキャンバスが見えてきました。
ここで群青に加わったコンポーネント
会計・給与6枚で実装まで到達した、または別の業界のキャンバスとして再利用されたコンポーネントです。
- EditableDataTable#37
明細行のインライン編集 + 税率別内訳を扱える表。請求書から介護報酬請求まで横断する金額表のキャンバス。
- AmountBreakdown#41
年末調整の還付/追徴が「ライブで」更新される箇所など、過不足を構造で見せる必要のある給与・税の画面に効く。
- DocumentRow#171
アイコン＋ファイル名＋メタ＋独立した DL ボタン＋選択チェックを安全に並べる書類行。ListCard.onSelect でカード全体が button になる入れ子問題を根治した。
- ApprovalWorkflow (proto)#39
経費精算の申請→承認/差戻し（差戻しはコメント必須）。後の不動産・公共の審査ワークフローと合わせて 3回確認へ。
DocumentRow は HR の書類セルフサービス（#171）が 3回確認の決め手となり、AmountBreakdown / EditableDataTable は他業界の金額画面で何度も再発見され続けています。
会計・給与 の全ラウンド
会計・給与 カテゴリの 6 画面を、ラウンド順に並べています。各カードから cold AI が組んだソース、解説記事、デスクトップ／モバイルのプレビューに飛べます。
/invoiceコンポーネントは業界を越えて複利する。銀行で育てたコンポーネントが、業界を越えてそのまま効いた。
/journal罠は「業界の作法」が炙り出す。名前で検索できないピッカーの罠。
/expenseシリーズ初の満点。コンポーネントを作る投資は、翌回に満点で返ってくる。
/payroll作った投資は、業界を越えて翌回に返ってくる。直近2回で作ったコンポーネントが、両方とも新しい業界で即採用された。
/year-end作り切った層は、新画面で "組み合わせ" になる。直近で作った4つが、全部ゼロ摩擦で使われた。
/hr-documentsダウンロード書類の行が3回目でコンポーネントに。「既存コンポーネントでは構造的に無理」は、一番強い"作るべき根拠"。
この業界が gunjo に残したもの
会計・給与は、「数字が合うこと」を UI が機械的に保証する作法を群青に残しました。EditableDataTable はインライン編集グリッドのキャンバス、DocumentRow はファイルアイコン＋名前＋メタ＋独立した DL ボタンを安全に並べる行（カード入れ子の不正HTMLを根治）、AmountBreakdown は給与・税の「過不足を見せる」場面で繰り返し効きます。連載が「ほぼ戦わずに出荷できる」域に入った起点もこの業界でした。