UI/UX Notes: Bills, Contacts, Invoices, and Virtual Wallets

Tabs: Bills and Contacts; each tab has its own function; columns configurable; consider maintaining tab state if applicable.
Bill row UI: an icon represents the uploaded bill; the entire row should be clickable to view the bill.
Upload flow: document uploaded inline; initial state is draft; two‑pane concept with content on the left and upload on the right (or inline editing); aim to view while filling.
Inline editing: avoid heavy auto‑extraction; fields can be populated manually; some fields (date, due date, sender) could be auto-detected but remain editable; do not rely on auto-detection for UX.
Layout decisions: keep KPI at the top; editing in line for bills and their fields; ensure empty/new bill layout supports left content and right upload area.
Field handling: if fields are pre‑populated, still editable; if a document is new, provide empty editable fields on the left.
In general: simplify to a two-pane flow for new bills; the document viewer can be side-by-side with editable fields.

Grid supports multi-select for bulk actions; per-row actions remain; define and confirm column names.
Empty state for a contact: show high‑level contact info on the right and indicate no payments/invoices yet; offer actions to add payments or settlements.
Payment methods: different paths for adding settlements via Cycles or adding a virtual wallet address.
Wallet addresses (virtual): per contact, display a list of addresses with network, address, and balance; prefer a compact single-line presentation rather than a wide, multi-row layout.
Data model: addresses are added from the invoice flow and tied to invoices; not intended as a global static view but accessible per contact.

Default behavior: settlement via Cycles is preselected; currency chosen determines the wallet context.
If settlement via Cycles is enabled: the recipient must have a Cycles address on the contact; if not, allow input here, otherwise pull from the contact.
Payable in: an invoice attribute (not a property of payment methods); reflect the actual payment currency in the invoice context.
Two-section structure: Payment Methods (assets you’re willing to receive) and Settlement Details (virtual wallet addresses).
Payment methods: allow multi‑select of assets (e.g., USDC, ETH); show available balances or relevant hints.
Settlement details: mutual exclusivity between cycles and virtual wallet addresses; if Cycles is on, show the Cycles address; if not, show virtual wallet address options.
Network/address UI: initial launch supports Ethereum; wallet address fields can be static/display-only or simple inputs; address generation occurs when sending the invoice.
UI simplification: two toggles in the settlement area (Settlement via Cycles and Virtual Wallet Addresses) with explanatory text; network and address presented adjacent to each other.
UX note: show a simple tooltip/tooltip-like hint that a V‑band (virtual wallet) will generate after sending the invoice; transactions/history will be available per wallet address.
Transactions: transaction history for a wallet address is contextual to that payment method; test transactions are shown; no global amalgamation across all payments.

List view per contact shows: network (with logo), wallet address, balance; addresses are added from the invoice flow.
Layout: compress into a single-line row per address to save space; there should be a dedicated screen to view transaction history for a given address.
Launch scope: only Ethereum support at launch; addresses may appear as static display fields until used for an invoice.
History screen: after selecting an address, show a textual, Stripe-like transaction history (deposits, credits, and test transactions) in context to that address.

KPI: keep the bills KPI at the top; upload and editing occur inline.
Missing screen: add a per-address transaction history view after the address list (or a quick access path).
End-of-day target: move most screens to engineering by end of day; share updates and revisions with Fabio; plan a Monday check-in.
Collaboration notes: include feedback from guests on the call and ensure alignment with Stripe-like UX for transaction history.