- Excise tax is volume-based, not a percentage of the sale: wine is taxed per gallon while spirits are taxed per proof gallon, with separate federal and state layers stacked on top.
- The invoice must compute proof gallons from quantity sold, apply the right per-unit rates, and summarize the total, which is exactly the arithmetic that stalled the previous vendor.
- Follow configuration before low-code, and low-code before custom code, so a niche requirement stays a small, maintainable build rather than a separate tax product.
- Lock the invoice as final at delivery with a captured signature, and keep the customization on your own tenant with source code and documentation delivered to you.
This spring, the owner of a small wine-and-spirits producer told us his last software vendor got "overwhelmed" by one requirement: showing federal and state excise taxes, calculated correctly, right on the delivery invoice. It's a great example of a niche industry need that a flexible platform handles without drama.
Excise tax isn't a percentage
The first thing to understand is that excise tax doesn't work like sales tax. It's based on volume, not on the dollar amount of the sale:
- Wine is taxed per gallon (or per liter).
- Spirits are taxed per proof gallon, which factors in alcohol strength.
- And there are separate federal and state layers stacked on top.
So the invoice has to compute proof gallons from the quantity sold, apply the right per-unit rates, and summarize the total. That's arithmetic the system can do once it's set up correctly, which is exactly where the previous vendor stalled.
Configure first, customize only for the gap
The right approach to a requirement like this in Business Central, Microsoft's cloud ERP, is to solve as much as possible through native configuration, reach for low-code tools in the Microsoft Power Platform next, and only write custom code for the specific gap that remains. Excise calculation on the invoice is a small, well-defined customization, not a reason to buy a separate tax product or a heavier system.
A useful principle for any unusual requirement: configuration before low-code, low-code before custom code. Solving a niche need this way keeps the build small, keeps it maintainable, and keeps you from buying a whole platform to handle one calculation.
Two things worth pairing with it. You can lock the invoice as final at the moment of delivery, with a captured signature, so it can't be quietly altered afterward. And you keep any customization on your own tenant, with the source code and documentation delivered to you, so you're not handcuffed to a single partner to maintain it.
If you're in a regulated trade with a calculation that keeps tripping up your software, that's usually a sign you need a more flexible platform, not a more expensive workaround. We're glad to look at the specific requirement with you. Let's talk it through.