--commit --i-understand-this-writes-to-accounting.Verified live: document-level discount makes FlowAccount compute VAT on the discounted figure. --discount-mode document is the default.
First VAT day at Rama IV was Jul 7. These 91 come after it and post with vatType: 3. Conservative default: yes, because inventing 7% output tax the club never charged is a real accounting error. If they should have carried VAT, that's a POS data fix before backfilling.
Zero FOC lines exist at Rama IV today, so unverified against real data. --foc-mode keep records them at POS value, the only setting that can't break the subtotal identity.
Two are Stripe payment-link orders (฿4,500 + ฿13,900, June). Five are POS terminal orders from Sep 3, 12:04–12:09 with repeated amounts (฿14,600 ×3, ฿24,836 ×2) that look like test rows. A document can't be reconstructed without lines.
tip_cents is 0 on every in-scope order, so tip handling is unverifiable. Any order with a non-zero tip is refused rather than guessed.
The MCP exposes no credit-note endpoint. They're listed in the report for manual entry.
19–21 orders with no linked customer post as "Walk-in customer (POS)", overridable via FLOWACCOUNT_WALKIN_LABEL. No tax ID is ever invented.
The MCP posts to whichever company its token is bound to (X-Company-Id). Confirm Rama IV's revenue belongs there before any commit. The tool never switches companies.
Plausible for a padel bar, but worth one glance before posting ~1,000 documents.