Best Practices for Yuki Connection in Magento 2

✅ Always test with a single invoice before enabling automation
✅ Import ledgers from Yuki before configuring ledger settings
✅ Map all tax rules in Tax Rate Mapping before going live
✅ Enable Debug Mode during initial setup
✅ Create a matching BTW tax code in Yuki for each OSS country
✅ Use "definitief" invoice type for production, "concept" for testing

❌ Don't enable automation without completing ledger and tax configuration
❌ Don't skip the Tax Rate Mapping step
❌ Don't leave Debug Mode enabled in production
❌ Don't forget to create OSS BTW codes in Yuki before enabling OSS countries

Use case: Single store, selling to Dutch customers only, using standard 21% and 9% VAT rates.

Configuration:

Connection:

• Single connection, one Yuki administration
• Invoice type: definitief

Ledger Accounts:

• Product: Omzet account (e.g. 8000)
• Shipping: Omzet account (e.g. 8000)

Tax Rate Mapping:

• NL BTW 21% → Hoog
• NL BTW 9% → Laag

OSS:

• Disabled

Result: All invoices automatically sync to Yuki with the correct Dutch VAT codes.

Use case: NL-based shop selling to consumers across the EU, using the One Stop Shop (OSS) VAT scheme.

Configuration:

Connection:

• Same as Scenario 1, plus OSS enabled

OSS Settings:

• OSS: Enabled
• OSS Countries: select all EU countries you actively sell to

In Yuki (before enabling OSS):

• Create a BTW code with type 40 for each OSS country, matching the local VAT rate for that country

Tax Rate Mapping:

• Map each EU destination country rate to the corresponding BTW code

Result: Domestic NL orders use standard Hoog/Laag codes. EU B2C orders automatically use VATType 40 with the correct country code, matching the OSS BTW codes you created in Yuki.

Tip: Use the Import Info button after adding new BTW codes in Yuki — this refreshes the available tax codes in Magento.

Use case: Multiple store views or websites, each connected to a separate Yuki administration.

Configuration:

Per store view:

• Enable connection separately per store view
• Use a different API key per store, or the same key with a different administration selected
• Configure ledger accounts per store view
• Adjust invoice descriptions per store if needed (e.g. include store name)

Result: Each store view syncs independently to its own Yuki administration. Orders from store A won't appear in administration B.

Use case: Selling to business customers within the EU with VAT reverse charge (intracommunautaire levering).

Configuration:

Tax Rules:

• Set up Magento tax rules for 0% EU reverse charge

Tax Rate Mapping:

• EU reverse charge → ExportBinnenEU

General Settings:

• EU No Tax Fallback: ExportBinnenEU

OSS:

• Not needed for B2B

Result: B2B EU invoices sync to Yuki with the ICP VAT code (VATType 7 / ExportBinnenEU). No OSS configuration required for business-to-business transactions.

Why it's wrong: Yuki will return an API error when the module tries to submit an invoice with a VATType 40 code that doesn't exist in your administration.

Correct approach: Create the BTW code in Yuki first (type 40, correct percentage, correct country), then click Import Info in Magento, and only then enable the OSS country.

Why it's wrong: The ledger dropdowns will be empty if you haven't imported from Yuki yet. You'll end up saving without a ledger selected, which causes sync errors.

Correct approach: Connect your API key, click Import Info, save, then configure ledger accounts.

Why it's wrong: Without explicit mappings, invoices fall back to the default tax class, which may not match the correct Yuki BTW code. This silently produces incorrect VAT declarations.

Correct approach: Map every tax rule you use in Magento to its corresponding Yuki BTW code before enabling automation.

Why it's wrong: Concept invoices are not finalized in Yuki. They won't appear in VAT reports and require manual action to process.

Correct approach: Use definitief for production. Only use concept during initial testing when you want to review invoices in Yuki before they're finalized.