You pick invoicing software, roll it out across the team, issue 500 invoices, then your accountant tells you during final review that the platform doesn't handle tax ID validation, rounding breaks your books by ₹3,000, and multi-entity invoicing doesn't sync to the GL. Now you're three weeks from audit and rebuilding invoice exports. This is preventable. Your accountant should vet the invoicing platform before you buy it, not after. Here are the seven questions that catch the gaps. 1. Does it validate tax IDs against live government registries? Tax ID validation is not optional in Southeast Asia. Malaysia's LHDN, Indonesia's NPWP, Singapore's UEN—each has rules. A validated tax ID gates whether an invoice is compliant. Most platforms either skip validation entirely or run it offline, meaning invalid IDs slip through. When LHDN or Direktorat Jenderal Pajak processes your submission, the invoice bounces. You've already sent it to the customer. Ask your accountant: Does the platform validate tax IDs in real time against government registries, or only check format? What happens if validation fails—does the invoice lock, or does it post anyway? Does the platform retry validation if the registry is temporarily down? For multi-country invoicing, does it swap validation rules by country? If the answer is 'it checks the format' or 'we let the accountant review it,' you're manually validating 500 invoices per year. That's not scalable. 2. How does it handle invoice numbering across entities? Invoice numbering sounds simple. It isn't. If you operate multiple entities (different tax IDs, different registrations), each entity must have its own sequential number series. Mix them, and auditors flag it. Regulators in Indonesia and Malaysia will reject batch submissions if numbering breaks the sequence. The platform must: Support separate number series per entity, not just per user or per customer. Never allow a gap or reuse in the sequence, even if an invoice is voided. Stamp the entity's tax ID on every invoice automatically. Block users from manually overriding the number. Many platforms treat entity as metadata but still sequence all invoices together. That works for a single company. It breaks the moment you have two. 3. Which rounding rule does it use, and can you override it? Rounding is the invoicing trap no one talks about. If you invoice in SGD but your GL is in USD, or if tax is calculated on a line item that's 1/3 of the total, rounding differences appear. A 0.01 error per invoice across 500 invoices is ₹500 unreconciled. Worse: different platforms round differently. Some round to the nearest cent after tax. Others round tax, then add. Some platforms let you set it; others hardcode it. Ask your accountant: What rounding rule does your GL use? (Usually: round after all calculations, half-up.) Does the invoicing platform match that rule, or force a different one? If you have multi-currency invoices, how does it round the FX rate? Can you override the rule per invoice, or is it platform-wide? If the platform hardcodes a rule that doesn't match your GL, reconciliation becomes manual. That's hours per month. 4. Does it pass MyInvois and e-Faktur validation in real time? Malaysia's MyInvois and Indonesia's e-Faktur are not optional. If you invoice in these countries, the platform must submit directly to the government system and handle rejections. Most platforms either don't, or submit asynchronously, meaning you don't know if the invoice passed until hours later. Test with your accountant: Does the platform have a live connection to MyInvois (Malaysia) or e-Faktur (Indonesia)? If submission fails, does the platform retry, or do you resubmit manually? Does it show the rejection reason in the UI, or do you dig through logs? Can you export invoices for manual submission if the automated route fails? If the answer is 'we integrate via a third-party service,' ask what the SLA is and what happens if that third party goes down. You'll be the one explaining to the customer why their invoice disappeared. 5. How does it handle multi-line tax and subscription proration? One-off invoices are simple. Subscriptions with mid-month changes, partial refunds, or tiered pricing are not. If you invoice on the 15th but the subscription starts on the 7th, you prorate. If the customer upgrades mid-month, you issue a credit and a new charge. If you operate in multiple tax regimes (SST in Malaysia, GST in Singapore), tax calculation per line gets complex. Most platforms either: Can't prorate at all (issue a full invoice, then manual adjustments). Prorate gross, not tax (tax is still calculated on the full amount). Support one tax regime, not multiple per invoice. Ask your accountant to test a real scenario: A customer on a ₹10,000/month subscription, invoiced on the 15th, signs up on the 20th. What does the first invoice look like? Is tax prorated correctly? If the customer upgrades mid-month, does the platform calculate the credit and the n