Café transaction: capture is not submission
A counter coffee order should retain its configured size and extras through settlement. The payment result is separate from the confirmed fiscal receipt.
Capture counter orders with configured sizes and modifiers, use recipes for beans, milk and syrups, take payments, and review stock and the daily close.
Confirm setup before real-time submission
Configure the business fiscal details, item/tax classifications and enabled, initialized eTIMS settings. Only real-time submission mode submits through the settlement path. Manual mode or disabled/uninitialized settings must not be described as automatic submission.
KRA distinguishes system-to-system solution types including online OSCU and VSCU. This page describes the DineHQ product workflow, not a certification claim, eligibility decision or tax advice. Confirm your registration and obligations with KRA or a qualified adviser.
Pending, failed and confirmed are different states
A paid bill does not prove a successful fiscal submission. Connectivity or provider errors can leave a pending/retry or failed state. Inspect the sale's fiscal status, check configuration and the error, and use the supported retry/resubmit action where available.
Do not label a pending receipt as confirmed, invent a QR code or repeatedly create a new sale to resolve a fiscal failure. Reprint after successful submission to include the returned fiscal details. Offline order recording cannot guarantee online fiscal confirmation.
Check your actual operating workflow
Recipe accuracy depends on recorded quantities and correctly configured modifiers. Do not assume a changed milk option automatically has the right stock recipe; test the configuration.
- Test sizes, milk options, extra shots and kitchen tickets.
- Count beans and milk; record waste rather than treating it as sales.
- Compare cash counted with recorded cash and verified M-Pesa.
- Review discounts and unresolved orders before counter close.