Every POS software list that integrates with QuickBooks stops at the same line. The tender row is where phone orders actually break your bank reconciliation.

A tender type (also called Payment Method, Payment Option, or Tender) is the row on a POS that classifies how a sale was paid for: Cash, Visa, Amex, Gift Card, Custom 1, Custom 2, and so on. When the POS-to-QuickBooks connector runs, it does not push one 'sales' bucket. It pushes one journal entry per tender type per day (or per transaction, depending on mode), each routed to a different QuickBooks account. Cash tender lands in your Cash-on-Hand or Undeposited Funds. Credit card tender lands in the processor clearing account. Gift card tender lands in a Gift Card Liability account. If a phone order's payment gets stamped with the wrong tender on the POS, it lands in the wrong QuickBooks account, and your monthly bank reconciliation will not tie out.

Phone orders split into two payment flows that look identical to a bookkeeper but settle through very different processor batches. Flow A is card-not-present: the voice agent tokenizes the caller's card at the end of the call, the POS captures it, and the funds settle via the processor's CNP batch (Stripe, Square CNP, Toast Card-Not-Present, Clover card-not-present). Flow B is pay-at-pickup: the order drops into the POS with no payment attached, and the card is swiped or dipped at the counter when the customer arrives, settling via the card-present batch at a different rate and often on a different deposit day. If both flows share one 'Phone' tender type on the POS, every QuickBooks entry for phone revenue goes to a single clearing line, and you will see phantom amounts in Undeposited Funds that never match the processor's deposit detail. Reconciliation breaks silently.

Clover: Merchant Dashboard, Setup, Payments, Tenders. You can add custom tenders and toggle whether each triggers hardware or opens the tip screen. Square: Dashboard, Account and Settings, Business, Payment Methods (and 'Other' tender types under the Checkout app). Toast: Toast Admin, Payments, Payment Options. You can mark a payment option as card-not-present, tip-eligible, and whether it appears on a specific service area. NCR Aloha: Manager Maintenance, Functions, Payments, Tenders. Aloha exposes the most granular control including clearing-account routing in the Back Office. Revel: Management Console, Settings, Payments, Tender Types. Lightspeed Restaurant: Back Office, Configuration, Tender Types. TouchBistro: Admin, Payments, Payment Methods. In every case the list is editable, and every POS-to-QuickBooks connector reads whatever labels you create there.

The signal is persistent Undeposited Funds that roll forward from month to month without matching specific bank deposits. Run the Undeposited Funds detail report in QuickBooks. If you see a line that says 'Phone Orders' with a total that never cleanly matches a Stripe, Square, Toast Processing, or Clover deposit, and the mismatches show up as small daily deltas that grow over the course of a week, the tender is probably mixing CNP and card-present (or mixing paid and unpaid phone orders). A clean reconciliation has each tender type settle to a specific deposit on a predictable lag. The remedy is splitting the phone tender into two rows and re-mapping each to its correct QuickBooks account in the connector.

PieLine's direct adapter writes each order to the POS with an explicit tender selection at the moment the call ends. If the caller tokenized a card on the call, PieLine calls the POS's payment endpoint with the card-not-present flag and posts the order under the CNP tender the restaurant has configured for phone-AI (e.g., 'Phone - AI - Card on File'). If the caller chose to pay at pickup, PieLine posts the order with no payment attached, and the POS settles the tender at the counter under the restaurant's standard in-store card tender or cash tender. This is the same path a human cashier would take, but performed by the adapter at call close with a machine-readable decision, not a guess. Both tender rows are standard POS configuration; PieLine tells the POS which one applies.

You can, and for very low phone volume it may not matter. The math only breaks when CNP and card-present deposits begin arriving on different days with different fee rates. Processor CNP fees run roughly 0.30 percent higher than card-present fees; if your phone channel is 10 percent of revenue and half of that is CNP, the fee delta alone is visible in your monthly P and L under Merchant Processing Fees. If you collapse to one tender, that delta attributes to 'phone orders' as a blob and you cannot break down the CNP premium by channel. For any restaurant running a voice agent at meaningful volume, splitting tender types is the lower-cost answer than reverse-engineering it monthly from processor statements.

Shogo is the most commonly referenced middleware because its core UI is literally a tender-type mapping grid. You connect the POS on one side, QuickBooks on the other, and Shogo shows a list of every tender label the POS returns alongside a dropdown of QuickBooks accounts. It is asking the same question this guide is: which QuickBooks account does each POS tender route to? Shogo's documentation explicitly flags that 'Credit Card tender types (tender types that will be part of a merchant services processor batch) may be grouped together in whole or in part or mapped individually.' That is the lever. Whether or not you use Shogo, the same question applies to every other connector (Commerce Sync, xtraCHEF, the native Square or Clover QuickBooks sync, Restaurant365): the tender-type mapping row is where the bank-reconciliation behavior is decided.

Yes. Both read the POS's tender list as-is and produce one journal entry per tender per day (summary mode) or per order (detail mode). Commerce Sync's default setup groups 'All Cards' into a single clearing account unless you explicitly split it. The Intuit Shopify Connector does the same for Shopify POS payment types. The tender-type granularity you get in QuickBooks is upper-bounded by the granularity on the POS, which is why the POS-side configuration matters more than the connector brand. Fix the POS tender list first, then verify the connector is not collapsing the distinction you just made.

No, tender type is a bank-reconciliation concern, not a revenue concern. Sales tax is calculated on the order total and posted against the tax liability account separately from the tender bucket. Splitting a 'Phone' tender into 'Phone - CNP' and 'Phone - PAP' only affects which bank or processor clearing account on the debit side; the credit side (Food Sales, Tax Payable, Tip Payable) is unchanged. Your 1099-K totals are the merchant processor's responsibility and will tie to the total card volume your POS sent to them, regardless of how you label the tender in your own books.

Six questions. First, how many custom tender types does the POS support? (Unlimited on Clover, Toast, NCR Aloha; limited on Square's native app, more flexible via Square's Custom Tenders; Revel and Lightspeed are configurable but capped.) Second, can a phone-AI integration partner set the tender type programmatically at order submission? Third, does the connector (or Shogo, Commerce Sync, xtraCHEF) let me map each tender to a distinct QuickBooks account? Fourth, does the connector run per-order or per-day summary, and does that change the granularity? Fifth, what happens on a processor batch close that spans a POS close-of-day boundary; does the connector still tie each tender line to the correct deposit? Sixth, can the vendor or integrator name a multi-location customer running a voice agent through a CNP tender row in production?

Read the tender-type documentation before the QuickBooks integration page. The QuickBooks integration page will always say 'Yes, connects to QuickBooks Online and Desktop.' The tender-type documentation tells you whether you can create a dedicated row for your phone-AI channel and whether that row can carry a card-not-present flag independent of your in-store card tender. Clover, Toast, NCR Aloha, and Revel all support this today. Square supports it via Custom Tenders with some constraints. Lightspeed Restaurant supports it fully. TouchBistro supports it. SpotOn supports it. Shopify POS is the most restrictive; if you are a restaurant running a voice agent on Shopify POS you will likely need Shogo or Restaurant365 as middleware to get the split you want in QuickBooks.