A Project Manager’s Guide

✅ Plants Abroad simplifies VAT for multi-country operations in one company code.

🌍 It was designed for EU transactions, automating tax and Intrastat reporting.

⚠️ Applying it outside the EU requires custom coding, adding complexity.

🔄 SAP ECC supports multi-country plants, but S/4HANA integrates it efficiently.

🇬🇧 Brexit complicates UK-EU movements; Plants Abroad no longer applies there.

“Plants Abroad” is an SAP term for functionality that allows a single legal entity (one company code in SAP terms) to operate with multiple VAT registrations in different countries. In essence, it lets a company treat warehouses or plants in foreign countries as part of the same company code, while still handling country-specific tax requirements. This was designed to simplify tax handling when a company has operations (like a warehouse or distribution centre) in another country but doesn’t want to set up a separate legal entity for that location.

The primary purpose of Plants Abroad is to ensure VAT compliance and reporting is handled correctly for cross-border transactions within the same company. For example, if a German company owns a warehouse in France, the Plants Abroad functionality allows the German company code to account for French VAT for the transactions out of that French warehouse, using the French VAT registration number. It automatically prints the correct VAT registration numbers on invoices and documents, applies the appropriate VAT rates, and captures movements of goods for reporting (such as Intrastat, the EU goods movement report). In summary, this feature enables:

• Multiple VAT Registrations in One Company: One company code can have VAT numbers in several countries, removing the need to create separate company codes for each country. This means a company can operate foreign plants or warehouses under the same financial entity while staying compliant with local VAT laws.
• Correct Tax Calculation & Invoicing: The system uses the VAT registration of the plant’s country for tax determination, ensuring the right VAT is charged and the proper VAT ID appears on sales and purchase invoices.
• Automated Cross-Border Postings: When goods move from one country to another within the same company (for instance, stock transfer from a plant in Germany to a plant in France), SAP can automatically create a self-billing invoice (known as a Plants Abroad invoice, document type WIA) to simulate a sale and purchase within the company. This internal invoice has no real financial impact (the company is just moving its own stock), but it generates the required tax entries for both countries.
• Simplified VAT and Intrastat Reporting: The relevant transactions are tagged with the tax reporting country, so they appear on the correct country’s VAT return and European sales/purchase lists. Intrastat declarations for movements of goods between EU countries are also facilitated without manual consolidation.

In short, Plants Abroad allows companies with warehouses or plants in multiple countries to manage VAT obligations seamlessly within one SAP entity, instead of juggling multiple company codes or manual processes to stay compliant.

Origin and VAT Compliance within the EU

The Plants Abroad functionality was initially introduced to support business transactions within the European Union. After the creation of the EU Single Market, companies often found themselves needing to move goods across borders without a sale (for example, transferring stock from a factory in one country to a warehouse in another). Even though these movements have no external invoice, EU tax law requires that they be reported for VAT (as a deemed “dispatch” and “acquisition”) and for Intrastat statistics. SAP developed Plants Abroad to address this scenario by automating the necessary postings and reporting.

Within the EU, a typical scenario is an intra-company stock transfer across countries. In standard SAP processing, you might create a stock transport order to move goods from Plant A in Country X to Plant B in Country Y. With Plants Abroad activated, when you post the goods issue for this cross-border transfer, SAP can generate a special internal billing document (the WIA self-invoice). This document creates the VAT entries for both sides of the transaction: it records an intra-community dispatch (sale) in the supplying plant’s country and an intra-community acquisition (purchase) in the receiving plant’s country. These VAT postings are then picked up by the VAT return of each country – ensuring that both countries’ tax authorities get the required reporting. The functionality thereby simplifies compliance with EU VAT rules: the UK company in our example would include the dispatch in its UK VAT statements and the French acquisition would appear in France’s VAT reports, all generated from one internal process.

Another key aspect is Intrastat reporting. Intrastat is an EU requirement to report statistics on the movement of goods between EU member states. Normally, if each country is a separate company code, each company code reports its own Intrastat for goods sent/received. With Plants Abroad, if a single company code is moving goods between two EU countries, the system knows to record an Intrastat entry for the dispatch from the source country and the receipt in the destination country – again, automatically via that internal billing document. This spares project teams from creating custom solutions to track stock movements; the SAP standard covers it as long as Plants Abroad is active.

It’s important to note that while Plants Abroad greatly assists with VAT reporting and currency handling for VAT (it even introduces an extra currency field to track tax amounts in the required local currency), it does not magically handle all tax calculation logic in complex scenarios. Companies still need to set up appropriate tax codes and determination logic. In fact, SAP’s standard tax engine (in ECC and S/4HANA) has limitations for very complex VAT flows. Plants Abroad addresses reporting and structural issues (like needing the right VAT number and currency), but companies with elaborate tax rules (e.g. multiple special cases) might still need additional tax configuration or even third-party tax engines. In the EU context, however, the main hurdles of getting the correct VAT treatment on intra-community transactions and simplifying compliance are exactly what Plants Abroad was built for.

Applying the Concept Outside the EU (Non-EU Countries)

By design, SAP’s Plants Abroad functionality is meant for intra-EU scenarios – where the movements of goods occur between EU member states. The standard system restricts its use to those cases. If one or both of the locations are outside the EU, the standard Plants Abroad process will not trigger. In SAP terms, if you try to move stock from an EU country plant to a non-EU country plant (or vice versa), the delivery will not be marked as relevant for billing, meaning SAP will not create the WIA self-invoice or any VAT postings for that transfer. SAP essentially says: “This isn’t an EU intracommunity scenario, so I won’t apply Plants Abroad logic.”

However, businesses do have similar needs outside the EU. For example, a company might want to move goods from a warehouse in France to a warehouse in Switzerland (Switzerland is not in the EU) under one company code, and automate the tax postings. Standard SAP won’t handle that out of the box – but it can be achieved with custom coding. In practice, SAP consultants have used user exits and enhancements to extend the Plants Abroad concept beyond the EU. Specifically, a user exit named LV50PFZA (in the SD module) can be modified to force SAP to treat those non-EU stock transfers like Plants Abroad transfers. This custom code basically overrides SAP’s check and allows the billing document (WIA) to be created for cross-border movements even if, say, France to Switzerland. Additionally, some adjustments in pricing or tax procedure configuration are needed so that the VAT posting is one-sided (for an export/import scenario, as non-EU movements require a different treatment than EU reverse-charge).

It’s crucial for project managers to understand that using Plants Abroad outside the EU is not a standard feature of SAP – it’s a custom solution. SAP delivered the functionality for EU use-cases and later also for certain other specific regions (e.g. Gulf Cooperation Council, GCC, had some similar concept for VAT within those countries). But generally, if your company wants to use one company code across countries like the US and Canada, or UK and Switzerland, standard SAP will not automatically handle the tax. You would be looking at bespoke development (ABAP coding) or considering a different approach (like keeping separate company codes). Custom coding to extend Plants Abroad should be approached cautiously: it carries maintenance overhead and is not officially supported by SAP for all scenarios. In short, outside of SAP’s intended scope (EU and similar unified markets), “Plants Abroad” can only be achieved by tailor-made enhancements.

SAP ECC versus SAP S/4HANA: Handling of Plants Abroad

Both SAP ECC (the older SAP ERP system) and SAP S/4HANA (the newer generation) offer the Plants Abroad functionality, but there are differences in how readily they support it and how efficiently it can be used:

• SAP ECC (ERP Central Component): Plants Abroad existed in ECC, but it was not widely implemented by businesses running ECC. In theory, an ECC system could be configured to use it for EU transactions, but there were practical hurdles. One issue is that activating Plants Abroad in ECC is a client-wide setting – once turned on, it affects all company codes in that client. This global activation sometimes made companies hesitant, especially if only one part of the business needed it. Additionally, ECC’s standard tax logic had gaps for complex scenarios, meaning if you did try to use one company code with many countries’ VAT, you had to manage a lot of custom tax condition records and perhaps manual adjustments. Many ECC users found it simpler to just create separate company codes per country (to clearly segregate VAT handling) rather than enable Plants Abroad and deal with its configuration. Indeed, there was even resistance from some SAP architects and project teams – the very name “Plants Abroad” led to misconceptions that it required drastic structural changes. As one source notes, many SAP architects were not willing to approve activating it, often misunderstanding the need to “create another plant abroad” in the organisational structure. The result was that under ECC, the feature was under-utilised and not very efficient for those who did attempt it without additional tools. Companies that truly needed multi-country VAT in one entity often ended up using third-party tax add-ons or custom code to fill the gaps. In summary, ECC could support the concept on paper, but doing so often introduced complexity and required careful workarounds, reducing the appeal of the standard solution.
• SAP S/4HANA: In S/4HANA, the concept of Plants Abroad remains largely the same – it is still the SAP-provided way to handle multiple VAT registrations under one company code, mainly for EU scenarios. However, S/4HANA comes with a more modern technology stack and some improved localization support. For instance, S/4HANA’s Advanced Compliance Reporting (ACR) is a new reporting framework that can better handle multi-country VAT reporting outputs, which complements the Plants Abroad setup when producing VAT returns and Intrastat reports. The fundamental configuration of Plants Abroad in S/4HANA (activating the setting, maintaining foreign VAT registrations, using tax codes with a “tax country” field) is similar to ECC. The key difference is that S/4HANA is the go-forward platform, so SAP and partners are focusing their support and enhancements here. If any new country-specific requirement or Brexit-related adaptation is needed, it’s likely to be delivered for S/4HANA first. For example, S/4HANA had updates to cater for Brexit changes (like distinguishing Northern Ireland transactions) through notes and patches. Performance and data model improvements in S/4HANA also mean that having additional fields (for tax reporting country, etc.) and doing the extra internal billing doesn’t carry a noticeable performance penalty – the system is built to handle big data and real-time postings, which aligns well with the needs of potentially more frequent cross-border postings in a consolidated entity.

It’s important to clarify that SAP ECC’s inefficiency with Plants Abroad isn’t because the functionality doesn’t exist – it’s because it wasn’t fully integrated into companies’ processes due to the effort and risk perceived. In S/4HANA, companies are revisiting this, because running one unified system is a common goal of digital transformation. SAP S/4HANA encourages simplification of the system landscape. Thus, if splitting company codes just for VAT was an old workaround, now a company might consolidate and use Plants Abroad to reduce the number of company codes (simplifying finance and consolidation) while still meeting VAT requirements. SAP S/4HANA’s deeper integration across modules (Finance, Sales, Procurement) means that Plants Abroad touches all relevant areas – when activated, new fields and functions appear in SD, MM and FI transactions to support it. Those fields (like “Tax Reporting Country” on tax codes and documents) are standard in S/4 and ready to use, whereas in ECC they might have required implementing specific OSS notes or support packages to get the latest functionality.

That said, even in S/4HANA the standard logic for non-EU scenarios has not fundamentally changed – SAP still expects you to use Plants Abroad mainly for EU countries. If your scenario extends beyond that (for example, a plant in a non-EU country), you would face the same need for custom coding or an alternative approach as you did in ECC. The difference is that in S/4HANA, you’re better positioned to manage and maintain such customizations, and SAP is continuing to patch and support edge cases (especially around Brexit, which effectively made the UK an “external” country from the EU perspective – more on this next).

In summary, SAP ECC did not efficiently support Plants Abroad because companies often avoided using it (due to complexity, misconceptions, and the need for custom work for non-standard scenarios), whereas SAP S/4HANA provides a more robust environment to leverage this functionality with improved reporting and ongoing support. Project managers should view S/4HANA as an opportunity to implement Plants Abroad properly if it fits the business model, and thus eliminate some manual processes that might have been used in ECC to compensate for multiple VAT registrations.

Brexit Impact: UK-EU Transactions and Added Complexity

Brexit (the UK’s exit from the EU) significantly changed the landscape for companies operating in both the UK and EU countries. A UK-based company with additional legal entities or operations in the EU now faces new challenges in handling transactions between the UK and EU (for example, between the UK and Ireland). Prior to Brexit, the UK was part of the EU’s single market, so movements of goods between the UK and an EU country like Ireland were considered intra-community transactions. They could be handled under the Plants Abroad model if within one company code, or as standard intercompany EU sales with zero VAT and reporting via EC Sales List and Intrastat if between two company codes. Post-Brexit, as of 1 January 2021, the UK is treated as a “third country” to the EU, meaning those same goods movements are now imports and exports rather than intra-community transfers.

For SAP processes, this has a few important implications:

• Intra-Community vs. Import/Export: A transaction that used to be an intra-community transfer (e.g. UK to Ireland stock movement) now requires customs declarations and import VAT handling. In SAP terms, if a UK company code was sending goods to an Irish company code, earlier you might have used VAT code for “EU dispatch/acquisition” (often zero-rated sale in UK with a reverse charge in Ireland). After Brexit, the UK company will use an “Export” tax code (zero-rated as an export, but categorized differently for reporting) and the Irish company will treat it as an import (with possible import VAT that may be reclaimable). Plants Abroad functionality is essentially an intra-community concept; it does not apply to UK-to-EU movements anymore, since one side (UK) is not EU. A UK company cannot use the standard Plants Abroad self-billing for a UK-to-Ireland stock transfer in SAP because the system will not consider that an EU intracommunity scenario. In practice, companies have had to revert to classic intercompany processes for such trade: the UK side issues an actual intercompany invoice to the Ireland entity and normal purchase/sales processing occurs.
• Northern Ireland Protocol: A special complication is Northern Ireland (NI). Under the Brexit agreement, NI (while part of the UK) is treated as if it were still in the EU for goods trade purposes. This means a UK company might continue to have an “XI” VAT registration for Northern Ireland in addition to the “GB” VAT for the rest of the UK. SAP had to accommodate this unique situation. For example, stock transfers from a plant in Great Britain (GB) to a plant in Northern Ireland within the same company code are now treated like cross-border transactions that require VAT reporting. In fact, SAP advises that a Plants Abroad invoice is required for stock movements from GB to NI after Brexit (Brexit and the Impact on SAP Customers. Part 8). This is a rare case where a company code (UK) has two VAT designations (GB and XI) post-Brexit. SAP delivered notes to handle NI specifically, introducing region codes and adjustments so that if a delivery is to NI, the system knows to generate the correct tax output (using the NI VAT number on the invoice, etc.). Project managers should be aware that Brexit introduced such exceptions, and ensuring the SAP system is updated for them (via notes or S/4HANA upgrades) is crucial.
• Fiscal Representation and Legal Setup: From an organisational perspective, many UK companies re-evaluated how they operate in the EU post-Brexit. Some chose to establish separate EU subsidiaries or legal entities (like setting up a company in Ireland or Germany) to handle EU operations, rather than having the UK entity continue to sell or distribute within the EU. This is because a UK company now faces things like needing an EU fiscal representative in some countries if they keep a direct VAT registration, more complex VAT filings, and potential delays at the border. In SAP terms, creating a new legal entity means a new company code, separate from the UK company code. That avoids needing Plants Abroad between UK and EU (since transactions will then be true intercompany sales/purchases between two company codes). However, it increases the number of intercompany transactions and data to reconcile. On the other hand, if a UK company decided to maintain a foreign VAT registration in an EU country (without a separate company code), they would theoretically want to use Plants Abroad to handle that – but as noted, standard SAP won’t cover UK-to-EU in Plants Abroad mode. They would have to implement custom logic to treat the UK as if it were still in the EU for that purpose, which is not standard and thus not generally recommended. The more straightforward path in most cases has been to treat UK-EU transactions as external trade, adjusting SAP configuration accordingly (new tax codes for exports, imports, changes to customer/vendor master data for EU vs non-EU flags, etc.).
• Complexity of UK–Ireland Transactions: Focusing on the UK and Ireland example, let’s consider a UK parent company with a subsidiary in the Republic of Ireland. Before Brexit, if they moved goods between a UK warehouse and an Irish warehouse, they might have relied on EU simplifications. Now, every such movement is an export from the UK and an import into Ireland. The Irish entity likely needs to account for import VAT (possibly using postponed accounting to avoid cash payments, depending on Irish rules), and the UK needs to zero-rate the export but keep evidence for customs. In SAP, this could mean setting up new tax codes: one for UK export to non-EU (to ensure the invoice carries 0% VAT but is marked as an export for reporting), and one for Ireland import VAT (usually a 0% entry if using postponed accounting, or a mechanism to record the import VAT and reclaim). Additionally, Intrastat reporting between UK and EU ceased (UK no longer files Intrastat for most goods, and Ireland no longer counts UK in its Intrastat from 2021, except Northern Ireland trade is still counted). So any automated Intrastat that Plants Abroad handled is now irrelevant for UK-EU movements, replaced by customs export/import documentation requirements which are outside standard SAP SD flow (often handled by SAP GTS or external freight systems).

The bottom line for project managers is that Brexit added layers of complexity for companies straddling the UK and EU. When planning an SAP S/4HANA migration or template design for a UK-based company with EU operations, one must consider that the once unified approach (EU plants abroad) no longer applies straightforwardly to the UK. You will either manage UK-EU transactions as intercompany (with all the tax and customs setups that entails), or if attempting a unified company code spanning UK and EU, be prepared for significant custom development and compliance challenges. Most choose to keep UK and EU as separate company codes now for clarity. However, within the EU side (like between Ireland and, say, France if the Irish entity has a French warehouse), Plants Abroad could still be a very useful feature – the EU side of the business can use it among EU countries, while the UK side stands alone.

In summary, Brexit means re-evaluating the use of Plants Abroad. For purely EU internal trade, it’s still valid. For UK-to-EU trade, standard SAP treats it as external trade, so the strategy shifts to intercompany processes or bespoke solutions. Project managers should ensure their teams update all relevant master data and tax settings (for example, marking UK as a third country in tax condition records, maintaining the new “XI” country code for Northern Ireland in SAP if applicable, etc.) to remain compliant in the post-Brexit scenario.

InHouse Secure Example: Current State and S/4HANA Changes

To make this more concrete, let’s use InHouse Secure as an example. InHouse Secure is a UK-based company that also operates in the EU via additional legal entities (for instance, a subsidiary in Ireland and perhaps others in Europe). Under their current SAP ECC system, they have not implemented the Plants Abroad functionality. Each legal entity is set up as its own company code in SAP, each with its own country-specific VAT registration and financial records. For example, they have company code IHDE for the German business and company code IHFR for the French business. Transactions between Germany and France entities are handled as standard intercompany sales/purchases: the UK entity sells to the Ireland entity (with an invoice in SAP) and the Ireland entity records a purchase. This means VAT between them is handled just as external trading partners – historically as an EU intra-community sale/purchase (zero VAT on the German invoice, acquisition tax in France).

Now, as InHouse Secure plans the migration to SAP S/4HANA, what changes do they need to consider regarding Plants Abroad? There are a few considerations:

• Will InHouse Secure use Plants Abroad in the future? The team should decide if there is a business case to consolidate any of their operations into a single company code with multiple VAT registrations. For instance, if InHouse Secure has a small operation in another EU country that is currently run as a separate entity, they might consider merging it into one of the existing entities and using Plants Abroad to handle the extra VAT registration, in order to reduce the number of company codes and simplify consolidation. If the answer is “no, we will keep each legal entity separate as before”, then they might continue not to use Plants Abroad in S/4HANA either. There is no requirement to activate it if it’s not needed. Many companies migrating to S/4HANA keep the same organisational structure they had in ECC, at least initially, to minimise disruption.
• If they choose to enable Plants Abroad (scenario): Suppose InHouse Secure decides that in S/4HANA, the German operation will remain a separate company code (since it’s a separate legal entity), but they use the distribution warehouse in France. Instead, they want the German company code to stock goods in France and sell locally. In that case, the German company code would register for French VAT and have a plant in France. This is a classic Plants Abroad scenario. To support this in S/4HANA, InHouse Secure would need to activate the Plants Abroad functionality in the system configuration (a one-time global setting) and enter the French VAT registration number against the German company code (SAP provides a configuration for “Enter VAT registration numbers for plants abroad”). They would then set up French-specific tax codes under the German company code, marking those tax codes with France as the “tax country” so that any transactions out of the French plant use French VAT rates and report under French VAT. They would also need to ensure their sales organisation and plant assignments allow selling from the French plant. In practice, the existing German sales organisation can be extended to include the French plant as delivering plant. The system, with Plants Abroad active, will take care of using the French VAT registration on the invoice to French customers and will include those sales in the French VAT return data (while the financial posting still sits in the Irish company code books). Additionally, any stock transfers between German and France within that company code would trigger the Plants Abroad process (the WIA self-invoice) to record VAT on moving stock to France and then to Germany when it returns or is sold, as applicable.
• Custom Code for Non-EU (if relevant): If InHouse Secure had a scenario of moving goods between the UK and an EU country within one company code (which is currently not the case – they use separate codes), they would hit the limitation we discussed. Since UK is non-EU now, such a scenario would need custom code. This might not be relevant unless they plan something unusual like a branch of the UK company in the EU without making it a separate company code. It’s more likely they’ll keep UK separate. However, if they had a scenario like moving goods from an EU plant to a US plant under one entity, that too would require custom solutions. Project managers should flag these scenarios early: they are non-standard and require additional development. The default move in design workshops would be to avoid them unless truly necessary for business reasons.
• Organisational Data Alignment: InHouse Secure’s project managers must ensure that everyone understands the roles of company codes, plants, and sales organisations when implementing or deciding against Plants Abroad. In ECC, they perhaps had a straightforward mapping: each company code corresponded to one country and had its own sales organisation for that market. If Plants Abroad is introduced in S/4HANA, they might not need new sales organisations for the new countries. The existing sales org can sell out of multiple country plants as long as VAT is correctly handled by the system. This simplifies sales structure but requires careful tax setup. Also, master data like material ledger or transfer pricing might be impacted; for example, an internal stock transfer within one company code (German to French warehouse) is not a profit-loss event, whereas intercompany (German company to French company) would be. Plants Abroad keeps it internal, which has accounting implications (no accounts receivable/customer invoice is generated, instead an internal document is created). The project team should document these differences so that finance and logistics teams at InHouse Secure know what to expect.
• Training and Change Management: Since InHouse Secure’s ECC users did not use Plants Abroad, the concept will be new to the business users and even some of the IT staff. As they migrate to S/4HANA, if they enable it, they will need to train users on how tax codes work now (for example, an Irish user creating a billing document from the French plant will see a French VAT code on the invoice – this might be unexpected if they’re used to everything being German VAT only). They will also have to adjust reporting processes: the tax department will retrieve VAT returns not just per company code, but potentially per “tax registration country” within a company code. S/4HANA’s tooling will allow this, but the team needs to know how to run and reconcile those reports.

In the current state, InHouse Secure’s ECC system avoids Plants Abroad by design – every country is handled separately. In the future S/4HANA system, to embrace Plants Abroad they would need to perform several setup steps (activation, VAT number entry, tax code configuration) and possibly develop custom logic if any scenario falls outside EU-to-EU transfers. These are configuration and development tasks the SAP consultants would carry out, but as a project manager, understanding them is important to scope the work and explain the changes to stakeholders. The benefit for InHouse Secure would be streamlined operations if they decide to use it: for example, fewer company codes to manage, more integrated inventory movements, and consolidated financials. The trade-off is the initial complexity in configuration and the need to adhere strictly to compliance in a multi-country context (which SAP supports, but the business must operate the processes correctly). If they choose not to use Plants Abroad even in S/4HANA, they essentially carry on with the status quo (separate entities) and focus on other improvements.

Key SAP Elements: Company Codes, Sales Orgs, Plants, and Tax Codes

To ensure clarity, let’s break down the key SAP organisational elements and their relevance in the context of Plants Abroad:

• Company Code: In SAP, a company code represents a legal entity – it’s the level at which a balance sheet and P&L are prepared. Normally, each company code has a default country (where it’s registered) and typically one primary VAT registration. Plants Abroad allows a single company code to have multiple VAT registrations (in multiple countries). This means a company code (legal entity) can operate as if it’s also a local taxpayer in other countries. Project managers should recognise that Plants Abroad does not change the fact there is one legal entity – it just extends its obligations. For example, InHouse Secure’s company code IHDE (in Germany) could also register for VAT in France if it had warehouses there. Without Plants Abroad, you would likely create separate company codes (e.g. IHFR) to handle those countries. With Plants Abroad, IHDE can cover all EU business transactions, simplifying the corporate structure (but increasing the compliance scope of one entity). It’s a strategic decision whether to combine countries under one company code – usually driven by legal, tax, and management considerations. SAP provides the tool (Plants Abroad) to make it feasible from a systems perspective.
• Sales Organisation: A sales organisation in SAP SD represents a selling unit (often aligned to a company code and region/market). In classical setups, if you had separate company codes for Germany and France, you’d have separate sales organisations for each to handle sales in each country. With a Plants Abroad scenario, you might use one sales organisation to sell from multiple plants in different countries (as long as they belong to the same company code). The sales organisation is responsible for the sales process, but the VAT treatment in a transaction will switch according to the delivering plant’s country when using Plants Abroad. This is important: you do not necessarily need to create a new sales organisation for a foreign plant if using Plants Abroad – the existing one can cover it, since the company code is the same. The invoice will show the company code’s name but with the foreign VAT number appropriate to the plant’s country. However, you might still choose to set up distribution channels or document series to segregate by region for reporting clarity. The key point is that the sales organisational structure can remain lean; you don’t need a full sales org and billing entity for each country if Plants Abroad is handling the VAT behind the scenes.
• Plant: A plant is a physical or logical location where goods are produced, stored, or distributed. Every plant in SAP is assigned to exactly one company code. Normally, you would only assign plants that are in the same country as the company code (to keep taxes straightforward). With Plants Abroad, you are explicitly allowing a plant to be in a different country than its company code’s country. The plant carries a country key (e.g. a plant might be marked as “FR” for France even though it’s under a German company code). That country of the plant is what SAP uses to determine if Plants Abroad logic is needed. If the plant country differs from the company code country, and Plants Abroad is active, SAP knows to check for a foreign VAT registration number and use it. For project managers, it’s crucial to track which plants are “abroad” relative to their company code. Each such plant will require a corresponding VAT registration entry in SAP and testing to ensure transactions from that plant behave correctly. Also, stock transfers between plants of different countries (under one company code) become a scenario to test (the WIA invoice creation, etc.). InHouse Secure, for instance, would list all plants and note if any plant’s country is not the same as the owning company code’s country – those are the Plants Abroad cases that need special attention.
• Tax Codes: Tax codes in SAP represent specific VAT rates and tax treatment (e.g. 20% standard VAT, 0% export, etc.). They are usually defined per country (each country has its own set of tax codes reflecting its VAT rates). In a traditional single-country company code, you use that country’s tax codes. When a company code has multiple VAT countries (Plants Abroad), SAP introduces a concept of “Tax Reporting Country” on the tax code. Essentially, you will create distinct tax codes for each VAT jurisdiction even within one company code. For example, if InHouse Secure’s INDE company code is also registered in France, you might create a French tax code (in the INDE company code’s tax procedure) and mark it as France for reporting. When posting a French transaction in INDE (via a French plant), you would use this French tax code so that SAP knows the output tax goes to France’s VAT return. The presence of a “tax country” field ensures the tax is reported in the correct country’s currency and forms. Without Plants Abroad, SAP assumes the tax country is the company code country. With it, you explicitly specify. Project managers don’t need to know the configuration steps, but they should understand that additional tax codes and careful mapping are required. One cannot just use the German tax codes for a French sale; the team will define new codes. This also means testing and validation by the tax team to ensure each code lands on the right VAT return (S/4HANA’s ACR or whatever reporting tool is used). It’s an area where close collaboration between the SAP functional consultants and the company’s tax specialists is needed.

In summary, company codes define the legal entity and books, sales organisations drive the selling process, plants provide the country context of goods, and tax codes determine VAT treatment. Plants Abroad ties these together by allowing the plant’s country (and an associated tax code) to override the default company code’s country for VAT purposes. As a project manager, ensuring that these elements are correctly set up and understood by both the implementation team and the business is critical for a successful rollout of Plants Abroad. You don’t need to configure them yourself, but you should verify that design decisions (like “we will use one company code for Germany and France” or “we will create separate tax codes for each country”) are documented and that the rationale is clear to all stakeholders.

Strategic and Operational Implications (No Deep Config Details)

It’s important to focus on the strategic and operational implications of implementing Plants Abroad, rather than the technical configuration details. From a high-level perspective, here are the key implications that project managers should consider and communicate:

• Compliance and Risk Management: Implementing Plants Abroad is fundamentally about compliance. It enables proper VAT reporting for multi-country operations within one entity, reducing the risk of errors that might occur if people try to handle those manually (for example, manually adjusting VAT reports for stock movements). By using the standard SAP functionality, you leverage SAP’s built-in logic to meet tax regulations. The upside is reduced tax compliance risk – VAT gets accounted for in the right country with system controls, which is critical to avoid penalties. The downside is that if configured incorrectly, it could misreport; so it must be done carefully. As a PM, ensuring that a tax compliance expert is involved in design and testing is an operational must.
• Simplification vs. Complexity: On one hand, Plants Abroad can simplify your SAP landscape (fewer company codes, fewer intercompany transactions). On the other hand, it complexifies a single company code’s internal processes. You are moving complexity from the org structure into the configuration. For example, instead of two company codes trading with each other (which is complex in consolidation but straightforward in concept: just a sale and a purchase), you have one company code doing an internal stock transfer with extra tax steps. Strategically, you are choosing to centralise operations – which often aligns with business goals of having one unified process – but you need to ensure the organisation is ready for that. There may be internal questions like “Which finance team will prepare the French VAT return if we don’t have a French entity, only the UK company with a French VAT number?” Such questions have to be resolved in policy (maybe the UK finance team takes it on, or a new centralised VAT team does it). Operationally, roles and responsibilities may shift because of this consolidation.
• System Maintenance and Master Data: With multiple VAT numbers in one company code, master data maintenance requires rigour. For instance, SAP allows you to store multiple VAT registration numbers per company code (one per country). When Plants Abroad is active, these must be kept current (if a VAT number changes, it must be updated in SAP). Additionally, customer and vendor masters need to have the correct VAT registration of the partner and often the “Partner tax country” may need to be set if you are selling to a customer under a foreign VAT scenario. This is operational detail, but it means the master data team’s workload might slightly increase. However, this is offset by not having to maintain duplicate master data in multiple company codes for what is essentially the same business partner. (In a consolidated approach, one customer master can be used to sell from multiple countries, instead of creating that customer in each country’s company code separately).
• Intercompany Transaction Reduction: A strategic benefit is the reduction of intercompany transactions. Every intercompany sale/purchase not only has to be processed, but also eliminated during financial consolidation. If InHouse Secure can reduce intercompany flows by keeping transactions intra-company, the accounting becomes cleaner. For example, moving goods from a German warehouse to a French warehouse under the same company code will not create accounts receivable/payable between entities (because it’s one entity) – it will simply move inventory. Financially, this avoids artificial profit markup and elimination entries. For the operations team, it might simplify transfer pricing issues as well. The operational implication is that controlling (management accounting) might need to adjust how they track profitability by region, since you won’t have a “sell/buy” in the financial books for those transfers. Instead, you might use an internal billing or pricing mechanism to attribute costs – or just treat it as a logistics cost. These are strategic choices influenced by whether Plants Abroad is used.
• System Limitations and Extensions: While we avoid deep config talk, project managers should be aware of limitations. For instance, Plants Abroad cannot be partially activated – it’s either on or off for the system client. You can, however, decide to only utilise it for certain company codes and simply not use it for others even if it’s on. There’s also the limitation around non-EU that we discussed. So, a strategic call might be: “Do we activate it at all?”. If only one out of ten company codes would benefit, and others are completely unaffected, you might still activate it (it won’t hurt the others) – but you must test that it doesn’t interfere. SAP assures that if you don’t maintain any foreign VAT for a company code, that company code behaves as usual, so it’s low risk to have it active. Knowing this, a PM can confidently approve turning it on, understanding that it won’t force changes in parts of the business that don’t need it.
• Post-Brexit Strategy: For UK/EU specifically, a strategic decision is whether to re-integrate any UK-EU processes under one roof in the future. Given regulatory realities, most likely not – the UK and EU will remain separate for the foreseeable future in VAT terms. Thus, InHouse Secure’s strategy (like many companies) might be to keep the UK entity separate, and possibly consolidate EU entities where feasible. This means Plants Abroad might be very relevant on the EU side (for example, one EU company code handling several EU countries’ operations), but not used for UK-EU between each other. A project manager should ensure that any Brexit-related adaptations (like Northern Ireland handling) are implemented by the technical team if needed, and that the design reflects the new normal (e.g., do not design a process that assumes seamless UK-Ireland internal transfers, since legally that’s not possible without treating it as external trade).
• Communication with Stakeholders: Boardroom executives will primarily be interested in the business outcomes – cost savings, compliance assurance, and simplification. The Plants Abroad concept can be communicated to them as: “This is an SAP capability that allows us to operate as one company across borders while still meeting each country’s tax laws. It can reduce internal complexity and overheads by not requiring separate entities everywhere, though it will require us to manage tax compliance centrally.” For SAP consultants, the project manager needs to ensure they have clearly in scope tasks like “activate plants abroad, set up tax codes, test cross-border scenarios, implement user exit if needed for X scenario”. So, bridging the gap, the PM might say to the board: “We plan to consolidate some operations to improve efficiency – SAP has standard functionality to handle the tax side of that (so we remain compliant and avoid risk).” Then to the consultants: “We need to configure and test the Plants Abroad features for these company codes, and document how we handle the reporting.” Maintaining an authoritative yet approachable tone means confidently stating what SAP can do, but also acknowledging where caution is needed (e.g. “We can enable this standard feature to handle our VAT registrations abroad, but we will proceed carefully to ensure all regulatory requirements are met”).

To conclude, Plants Abroad is a strategic tool in SAP’s arsenal for companies operating internationally. It aligns with modern business needs to centralise and standardise operations while staying compliant locally. As a project manager, you don’t need to know every configuration step, but you should understand the overall flow: activate the feature, link foreign plants with VAT registrations, use appropriate tax codes, and test the end-to-end business process (from stock movements to tax reporting) to ensure it works as intended. By focusing on the business implications – like how it simplifies the entity structure, what new responsibilities the central finance team might take on, and how it ensures compliance – you can make informed decisions and explain them to both executives and technical teams.

Remember that the goal is to have an efficient operation without sacrificing compliance. Plants Abroad, used in the right context (mainly intra-EU, or similar markets), helps achieve that by leveraging SAP’s built-in capabilities. But it should be applied with a clear understanding of its scope and limitations, especially in a post-Brexit world where the definition of “abroad” has shifted for UK companies.