Parsons Fine Wine Imports couldn't reconcile its own numbers every month. That's an ERP problem, not just a bookkeeping one.

Kirk Parsons co-owns Parsons Fine Wine Imports, a Georgian wine importer licensed in Indiana and Kentucky. The business ran on QuickBooks, and every month, he ran into the same wall.

"That's one of my biggest time consumers each month, reconciling," he said. "It doesn't always necessarily pull stuff correctly, and then I have to go back and research."

Reconciliation sounds like a small accounting task. For an importer, it's a symptom of something bigger: the bank, the books, the inventory, and the tax rules aren't living in one connected system. If they were, the numbers wouldn't need to be re-checked by hand every month in the first place.

Importing wine into two states doesn't mean one tax problem. It means two.

Parsons moves product between Indiana and Kentucky, and the two states don't treat that movement the same way. Indiana taxes it on the way out. Kentucky taxes it on the way in. Same wine, same transfer, two different tax events depending on which direction it's going.

A generic system doesn't know that distinction exists. Somebody has to catch it by hand, every time, on every transfer between states — on top of already reconciling the bank each month.

What actually needs to happen instead

Two things have to be true for an importer to trust its own numbers: the bank has to reconcile itself, and the tax rule has to be attached to the transaction, not to whoever happens to remember it that week.

Ruby Pro connects to the bank through Plaid, with feeds updating through the day, so the reconciliation Kirk described as his biggest monthly time sink isn't something he does by hand at the end of the month. And the Indiana-outbound, Kentucky-inbound tax difference gets built into the system at the state level, so it's applied the same way every time a case crosses the line — not re-derived by whoever's doing the transfer that day.

Once those two pieces are solid, everything downstream gets simpler — including pricing. You're working from a number you actually trust, not one you're hoping is close.

Built for a two-state importer, not shipped as a generic feature

The Indiana-outbound, Kentucky-inbound distinction isn't something Ruby Pro had sitting on a shelf for every importer. It's the kind of state-specific rule that gets built into a customer's setup based on how they actually operate — at no extra charge for the build.

Parsons' data stays Parsons' data. Ruby Pro makes no claim over it.