Incident
The ticket came in from the office manager at a small distribution business, forwarded on behalf of the owner who handles his own billing out of a separate property-management LLC. His message was straightforward: he could open QuickBooks, pull up the company file, create an invoice, print it, scan it — everything worked. But the second he clicked "Email Invoice," QuickBooks threw up a dialog:
QuickBooks is unable to send your email as you are signed out
of Intuit ID. Sign in to continue.
He clicked Sign In. The Intuit login window opened. And then it just sat there. No spinner progressing, no error, no timeout — hourglasses inside the window and nothing else. He tried his credentials. He tried the office manager's credentials. He restarted the machine. He went back and forth with her over email for ten days trying to guess at passwords. At one point he wrote, "You know you're dealing with the smartest, dumbest person you know." He wasn't dumb. The dialog was lying to him — no password was going to work because the auth handshake never reached Intuit's servers.
He was leaving for vacation in a few days and still had invoices to send.
Diagnostics
We signed in as him on his workstation and reproduced the hang immediately. Click Email Invoice, Intuit ID window opens, hourglasses, nothing. No error in the event log, no firewall block, no proxy in the way.
This matches a documented Intuit support thread where the embedded login window in QuickBooks Desktop hangs indefinitely — it's a known product issue, not a misconfiguration. Intuit's own community forum has threads going back months from current-version users hitting the same hourglass. Connected-services auth flows for QuickBooks Desktop have been flaky for a while, and the client-side behavior when the handshake stalls is the indefinite hang — no error surface, no timeout, just the spinner forever.
As a side note: QuickBooks Desktop 2020 and earlier are past end-of-life (May 31, 2023), and for those versions Intuit has fully deprecated connected-services auth — meaning the same hang is permanent and the only path is an upgrade. This client was on a current version, so their problem is the product bug, not EOL.
Why the password-hunting didn't work
The email thread was full of hopeful guesses — try a different Intuit ID, try the office manager's password, did the dialog give you a place to put it. None of that could have worked. The hang wasn't an auth failure. It was a handshake that never completed. No credentials were ever transmitted because the client never got that far.
The generic "repair your QB installation" / "reinstall" / "run QuickBooks Tool Hub" advice scattered across forums is also a long shot. People report all three fixing it, not fixing it, making it worse, or making it different. It's not a deterministic bug.
Resolution
We laid out three options with the office manager and the owner:
Route invoice email through our business mail server via SMTP. QuickBooks Desktop's Send Forms feature supports SMTP as an alternative to the Intuit-mediated "Email Invoice" flow. Configure the SMTP credentials in Edit → Preferences → Send Forms, and invoices send as normal email over your own mail server — no Intuit ID required. Setup $75, $15/month ongoing for mailbox and relay.
Export each invoice as PDF and email it from Gmail directly. Zero cost, works immediately, fine for a business sending a handful of invoices a week.
Keep QuickBooks on paid in-version updates through the product cycle and wait for Intuit to ship a fix — not a real plan for an owner with invoices due tomorrow.
For the immediate "I'm leaving for vacation" pressure, option 2 cleared all pending billing the same day. The office manager is evaluating option 1 for the longer-term fix.
Why routing through your own smtp works
QuickBooks' Send Forms has two transport modes: Webmail (Intuit-mediated, requires Intuit ID auth through the embedded browser) and Outlook / SMTP (direct handoff to an SMTP server you configure). The SMTP path doesn't touch Intuit's auth infrastructure at all — QuickBooks composes a MIME message and delivers it through whatever mail server you point it at. The broken component is sidestepped entirely.
That's also why this workaround holds up for EOL versions of QuickBooks Desktop where Intuit has pulled the plug on connected services — if you can get SMTP configured, email keeps working regardless of what Intuit decides to turn off next.
Outcome
The owner got all his December invoices out through Gmail before leaving town. No more hang, no more dialog. On the way out the door he told us the PDF-and-Gmail flow took him maybe two minutes per invoice, which he was fine with for now. The office manager is queueing up SMTP configuration and a broader Send Forms review for Q1.
status: workaround deployed same day, SMTP cutover planned cost today: $0 time to fix: one hour of diagnostics, five minutes to explain the PDF flow