Accounting Sync (myDATA, Billtrust)

Paid pluginsize Lplanned, not built

Indicative price, not an offer: €44/mo; credential & obligation: Greek myDATA API integration, weekly filing

Generated from docs/plan/paid/accounting-sync/PLAN.md in the AstroBaaS repository. Nothing described below is implemented — it is the written plan for it.

A paid service for merchants in countries with mandatory electronic invoicing or accounting ledger filing (Greece myDATA, Netherlands VAT SaaS, etc.). Auto-exports invoices in government-mandated format, weekly filing-ready reports, and audit trail proving compliance.

The problem

A Greek merchant is legally required to file all invoices with myDATA (the Greek tax authority’s electronic invoicing system) within 2 hours of issue. She currently exports to a CSV, manually converts it to XML, and uploads weekly—often late. The IRS fines merchants 100€ per missing invoice. She spends 3 hours per week on this.

What it does

• myDATA XML export: orders/invoices formatted to Greek myDATA XSD schema
• Weekly filing-ready report: all invoices from the week, status (filed/failed/pending)
• Auto-filing: optionally auto-submit to myDATA API (if credential is provided)
• Transmission ID tracking: every filed invoice gets a transmission ID from tax authority
• Error handling: if filing fails, merchant is alerted with error details, option to retry
• Audit trail: which invoices were filed, when, with which transmission ID
• Multi-country support: same interface for Netherlands, Spain, France (each has different format/API)
• Backfill: merchant can file invoices retroactively (e.g., catch up from last month)
• Support escalation: if myDATA API rejects an invoice (e.g., VAT mismatch), merchant can open ticket

What it deliberately does NOT do

Each boundary carries its reason. A boundary without a reason gets crossed by the next person who reads this.

• Invoicing—that’s core AstroBaaS. We just export/file invoices that already exist
• Accounting ledger entries (posting to GL)—out of scope; merchant uses accounting software
• Tax deduction tracking or VAT reclaim—out of scope
• Payroll or income tax filing—out of scope
• Countries beyond Greece/Netherlands/Spain/France initially—can expand later

Data model

New: AccountingSyncConfig(shopId, country_code, credential_id, auto_file=false); FiledInvoice(invoiceId, country, transmission_id, filed_at, mydata_response_json). Both stored in plugin settings, no core schema migration.

API

• POST /accounting/export/:country/:period — return filing-ready XML/CSV
• POST /accounting/file/:country/:period — submit to tax authority API
• GET /accounting/status/:country/:period — return filing status and transmission IDs
• GET /accounting/filed-invoices — list all filed invoices with transmission IDs
• POST /accounting/support-ticket — escalate filing error to support

Every route added here must also appear in src/pages/openapi.json.ts — a test fails the build if it does not.

Admin

Accounting sync panel: country selector, weekly filing status (which invoices are filed), transmission ID log, error alerts with retry button, backfill option (select date range), support ticket queue

The seam — why this is paid

Core owns: invoice generation, data structure. Paid pack owns: country-specific filing format (XML schema), tax authority API credentials, filing logic, error handling, quarterly updates if rules change.

Per-country obligation: Greek myDATA mandate, we maintain compliance, weekly filing

Dependencies

• invoice system (core; must generate invoices before filing)
• email layer (to alert on filing failures)

Acceptance checks

Each of these must be able to fail. Before claiming this is done, break the code deliberately and watch each one go red.

• A Greek merchant’s 200 invoices from week of Sept 1-7 are exported to myDATA XML format in <30 seconds
• Each invoice in export has: invoice number, issue date, customer VAT ID, amount, VAT, transaction type
• XML export passes validation against Greek myDATA XSD (can be tested with xmllint)
• Submitting export to myDATA API returns transmission IDs for all 200 invoices within 2 hours
• A filing error (e.g., ‘VAT amount mismatch’) is stored in audit log with error details
• Merchant can retry a failed filing; if it succeeds, transmission ID is updated
• Audit log shows which merchant employee filed which batch, when, with which transmission ID
• Backfill: selecting invoices from August 2024 allows filing them now (late); audit log marks as ‘backfilled’

Risks

myDATA API changes format or adds new required fields—all shops break until we update. Filing failures cascade: if one invoice fails, merchant must retry the whole batch. Transmission ID mismatch: tax authority accepts filing, but we store wrong ID—audit trail is wrong. Timezone bugs: invoice time in one timezone, filing time in another—missed deadlines. Credential expiry: if API key expires, filings start failing silently (must alert merchant proactively).

Commercial context

The anchor is what the nearest equivalent charges on Shopify or Magento today. It is context for a pricing decision, not the decision.

---

Generated from the commerce plan. See docs/COMMERCE-PLAN.md for the full catalogue and ../../AI-GUIDE.md for how to work on this repository.