Multi-entity accounting means keeping separate books and controls for each legal entity, then consolidating them into one reliable group view. For platforms with multiple companies, it starts by assigning each transaction to the correct entity, preserving entity-level journals, mapping accounts into a consolidation structure, reconciling intercompany activity, and eliminating intra-entity balances and transactions in consolidated reporting.
Multi-entity accounting works when you keep entity-level books and controls intact first, then consolidate with explicit rules. If your organization operates through two or more distinct business units under common ownership or control, the design should preserve separate records while still giving you one reliable group view.
A legal entity is the party legally or financially responsible for financial transactions, so those boundaries are a core accounting control. In practice, settle this early: which company owns the transaction before anything posts.
Settlement time is the time between payment or funding initiation and when funds become available. Funds become usable for payouts after settlement moves them into available balance, and transaction-level settlement reporting supports reconciliation at the operating layer.
A chart of accounts is the list of account names available for recording transactions in the general ledger. Different companies can maintain different COAs and still support unified reporting, as long as you map them clearly into the consolidation structure.
Under IFRS 10, control is the basis for consolidation, and a parent that controls subsidiaries is required to present consolidated financial statements. ASC 810 also requires eliminating intra-entity balances and transactions in consolidated reporting.
Intercompany reconciliation compares provider and receiver receivable and payable entries, and differences can arise, including from FX conversion-rate differences. Audit trails should be secure, computer-generated, and time-stamped so record actions can be traced reliably.
This article is for finance and operations owners running real payment flows. It follows the practical path from settlement event to consolidated financial reporting. It also covers the failure modes and checks that help your close hold up under pressure without losing control of intercompany reconciliation, audit trail quality, or payout execution.
We covered this in detail in The Best Accounting Software That Handles Multi-Currency Invoicing.
Use this guidance when you run more than one entity and need reliable group reporting. It is especially relevant when a parent controls subsidiaries, reports as a single economic entity, and has recurring intercompany activity that needs to be handled consistently in consolidation.
Use this when entity boundaries are legal and accounting boundaries, not just reporting labels. If your close depends on intercompany entries and eliminations, the platform design needs to support that flow directly.
If you keep separate records mainly for convenience and do not have regular intercompany activity or formal group consolidation requirements, a full multi-entity setup may be more than you need right now. Reassess when duplicate data or unclear ownership starts showing up in close.
Start with the output you need: does reporting present the group as one economic entity? Then test ERP fit and data behavior, including whether the setup reduces duplication. Check audit trail depth so records preserve enough transaction detail for control and review. Treat exception handling as an operational clarity test: can your team quickly see what failed, who owns it, and whether close is affected?
Spreadsheet handoffs between companies are a control-risk signal, especially when errors or ownership gaps can survive into close. If that is your current state, tighten control design before you add more automation.
That operating model choice shapes everything else for you. Your next step is to decide where errors should surface first and which system wins when finance and operations disagree.
If you want a deeper dive, read Gateway Routing for Platforms: How to Use Multiple Payment Gateways to Maximize Approval Rates.
Pick the model by deciding where errors must surface first and which record wins when finance and operations disagree. These are practical decision patterns, not an official taxonomy.
| Model | Best for | Key pros | Key cons | Concrete use case |
|---|---|---|---|---|
| ERP-led | Finance-heavy groups with strict accounting governance | Strong consolidated reporting, familiar controls, and consolidation support, including elimination subsidiaries in some ERPs | Settlement-event and payout-batch visibility depends on how tightly upstream feeds are controlled | Central finance owns close and consolidation; ops teams provide controlled inputs |
| Ledger-first | Teams prioritizing journal integrity and source-event traceability | Clear control over subledger-to-ledger transfer timing and source-event traceability | Requires explicit mapping into ERP outputs and consolidated reports | Teams need to trace each journal back to a source event ID |
| Payout-led | Ops teams managing high-volume disbursements | Strong payout-batch visibility, reconciliation to bank receipts, and per-entity payout reporting in some infrastructures | Entity accounting can weaken unless intercompany reconciliation and posting rules are explicit | Daily operations are driven by payout timing and settlement-batch control |
| Hybrid | Teams balancing finance control and operational speed | Combines close discipline with payout and settlement telemetry | Governance complexity if ownership boundaries are unclear | Finance needs reliable group reporting while ops needs fast payout and settlement monitoring |
Choose ERP-led when consolidation is the non-negotiable requirement. IFRS 10 ties consolidation to parent control over subsidiaries, and ASC 810 frames consolidated reporting as a single economic entity view.
The benefit is close discipline in a familiar system. Consolidated reporting can span multiple subsidiaries and, in some ERP implementations, include elimination subsidiaries. Operational visibility still depends on upstream design: settlement and payout issues are easier to catch early when subledger feeds and control points are explicit.
Choose ledger-first when traceable journals and event-level accounting control matter most. Subledger entries move to the ledger, and posting can be immediate or deferred, so you can decide where validation happens.
That timing control can improve auditability before data is pushed into ERP reporting. It works best when event-to-account mapping is strict and documented by event type, entity, debit or credit, intercompany treatment, and ERP destination.
The main risk is lag between subledger and ERP. Do not treat consolidated outputs as complete until source-event and journal-status views reconcile.
Choose payout-led when payout flow is your main operating control surface. Payout reconciliation can run through settlement batches, and payout reporting can be produced per entity on a daily, weekly, or monthly cadence.
This model improves day-to-day visibility for payout operations. It fits platforms routing payments and payouts across multiple counterparties. The risk is drift. Accounting can fall behind unless intercompany and posting rules are explicit. Keep a hard checkpoint in place: payout batch, bank receipt, entity attribution, and ledger posting all need to align.
Hybrid is a fit when you need disciplined consolidation and fast operating telemetry at the same time. This pattern is relevant when your payment lifecycle spans checkout, settlement and fees, and payout across multiple days.
A workable split keeps operational monitoring close to payout and settlement workflows while sending controlled entries into the ledger or ERP for close and consolidation.
A common failure mode is unclear ownership. If multiple teams can change entity mapping, intercompany treatment, or posting timing without review, fix governance first.
For a step-by-step walkthrough, see How Platforms Build Multi-Currency Sub-Wallets for Contractors.
We recommend not automating around a weak entity model. If your accounting spine is unclear, more tooling will not keep your consolidation and reporting from drifting.
Assign each transaction to the correct legal entity before first posting. Configure ledger details at that level rather than relying on one generic group setup. We recommend one simple checkpoint: for a sample settlement event, define which company owns the first journal.
Define the chart of accounts before transaction volume goes live, because once you post transactions in an entity, you cannot change that company's COA. A shared COA can support cross-entity consistency, while legal-entity overrides can handle differences in charts or account structures. Set account structures early so journal requirements stay clear and repeatable.
Pick one system of record for each company's first journal entry before building consolidated financial reporting. Consolidation gathers transactions from multiple account sets into one set. It does not replace entity-level accounting, and the consolidated entity is not for daily transactions. Consolidated reporting also requires intercompany transactions to be eliminated in full.
Document the posting sequence your team uses and apply it consistently across entities. Standardize journal fields so each entry carries clear entity ownership, account and dimension coding, posting date, currency, and intercompany details when relevant. This helps keep eliminations and consolidated reporting controlled instead of manual.
You might also find this useful: Accounting Automation for Platforms That Removes Manual Journals and Speeds Close.
Decide your COA model before deep ERP integration, because consolidation controls depend on that choice. The practical question is whether you want one shared account language across entities or local account languages mapped into group reporting.
A chart of accounts is the structured list of a legal entity's general ledger accounts. Supported models already exist for both approaches: keep the same COA between subsidiary and consolidated entities, or allow different COAs and map during consolidation. When ledgers use different COAs, mapping is required.
| Decision point | Global master COA with local mapping | Region-specific COAs with consolidation mapping |
|---|---|---|
| Core design | One organization-wide COA anchors entity books and group reporting | Each country or region can use a local COA, then map to group reporting |
| Best fit | Cross-entity consistency and centralized finance governance | Local statutory requirements and country-specific account structures |
| ERP implication | More standardized posting design across entities | Mapping is an explicit control for consolidation processing |
| Main tradeoff | Less local variance in account design | More mapping design and maintenance effort |
| Non-negotiable control | Entity accounts must roll into consolidation reporting | Local G/L accounts must map clearly to a consolidation target, for example an FS item |
If you prioritize cross-entity consistency, a master COA keeps account structure and group reporting logic aligned across entities. Using the same COA in subsidiary and consolidated entities is a supported setup pattern and can make cross-entity comparison more straightforward.
If local statutory reporting is the main driver, allow local COA variance and enforce mapped rollups to the group structure. This approach supports local COAs while still defining clear relationships back to the global structure.
In group reporting terms, G/L accounts map to consolidation targets so source FI data can be processed correctly, and FS items are the core consolidation assignment object. The key mapping rule is simple: multiple G/L accounts can map to one FS item, but one G/L account should not map to multiple FS items.
Before each close and each entity go-live, we recommend one verification checkpoint: every active account used in a company should map unambiguously to a consolidation node. Validate posted accounts against the approved mapping table and resolve unmapped, duplicate, or outdated mappings before consolidation.
Set close ownership before the period starts. Otherwise your close can look done while consolidation risk is still open. Build a close calendar with named owners for each entity and clear group-level consolidation sign-off ownership so material blockers are addressed before sign-off.
Treat the close calendar as an operating control, not just a timeline. Assign owners, due dates, and approvals for each task. Include escalation contacts by business unit, location, or country, and include all close participants, not just accounting roles.
Keep ready for entity close separate from ready for group close. Business-unit statement preparation and consolidated statement preparation are distinct steps, so one company can be complete while the group close is still blocked.
Escalate items that could influence decisions if omitted, misstated, or obscured, rather than letting them sit in normal backlog flow. Consolidated financial statements are meant to present the group as a single economic entity, so unresolved high-impact exceptions may need to delay consolidation sign-off until corrected.
With ownership in place, the next control to define is intercompany reconciliation.
Run intercompany reconciliation as a control before group sign-off. The aim is simple: confirm that entity-to-entity balances are correct at period end and resolve breaks before consolidation.
At a minimum, compare what each company recorded for the same intercompany activity, investigate discrepancies, and keep an aging log of open issues. Timing differences and FX treatment differences often surface here.
| Control point | Owner | Evidence | Pass-fail status |
|---|---|---|---|
Matched Intercompany transaction pairs | Entity accountants for both counterparties, with group reconciliation owner oversight | Counterparty references and linked journals in the General ledger where available | Pass if each entity-side entry has a corresponding counterparty entry; fail if unmatched or mismatched |
| FX-consistent settlement values | Group accounting or consolidation owner | Transaction currency, reporting currency, rate source, applied rate, settlement support | Pass if both sides apply the agreed FX logic for the same event; fail if an unexplained Exchange difference remains |
| Aging of unresolved breaks | Reconciliation owner | Open reconciling-items log, age bucket, owner, correction note | Pass if open items are logged, owned, and escalated per policy when needed; fail if stale, unowned, or not escalated |
| Period-end cutoffs | Entity close owner plus reviewer | Posting date, settlement date, period-end cutoff review, reviewer sign-off in the Audit trail | Pass if both sides are recorded in the correct period or the timing difference is documented; fail if cutoff treatment is unexplained |
Pair-level matching is the core test. Each transaction recorded by one company should have a corresponding entry in the counterparty's books. A net balance tie can still hide unresolved reconciling items.
Timing differences are a common failure mode, especially in 1 to many, many to 1, or many to many match patterns. In that environment, partial matching during the period keeps unmatched items down instead of pushing the whole problem to month end.
Some recon breaks are FX treatment breaks. Under IAS 21, the closing rate is the spot exchange rate at the end of the reporting period. Both sides need to apply consistent rate logic to the same internal item.
This matters because intra-group balances and flows are eliminated in full. When two entities carry different values for the same internal balance, elimination work becomes more manual. If you need a deeper operating view, this is closely related to reconciling multi-currency payouts across multiple PSPs.
Not every break deserves the same response. Use your policy to prioritize by value, risk, and operational impact, and define when to escalate.
The red flag is aging without ownership. A log becomes a control only when issues are owned, aged, and escalated when required.
Decide the evidence pack in advance so reviewers can trace open items quickly and consistently. In practice, evidence packs often include counterparty references, supporting ledger links where available, and reviewer sign-off in the Audit trail.
When you evaluate platforms, look closely at whether those links survive through close, elimination, and review. If they do not, intercompany control will stay more manual than it looks on the demo.
This pairs well with our guide on How to Let One Customer Hold Multiple Plans on Your Platform.
If your control table is defined but execution is still manual, review Gruv's implementation patterns for idempotent events, audit trails, and payout-state visibility in the developer docs.
The core control is simple: payout operations and finance need to resolve to the same money movement before close. Define a traceable operating sequence for your platform, then verify it end to end against entity journals and reconciliation evidence.
| Control point | What to link or verify | Note |
|---|---|---|
| Operating sequence | Settlement event intake, ledger posting, payout eligibility checks, payout batch execution, and final reconciliation status | Each stage should carry an identifier that persists into the General ledger and the Audit trail |
| Async delivery | Delayed or non-final responses, plus stale, partial, out-of-order, or duplicated webhook payloads | Retries need to be duplicate-safe and auditable |
| Retry chain | Original provider event reference, each retry attempt, and the final posting outcome | Keep the full chain visible in the Audit trail |
| Payout completion | Each paid batch, its posted journal, and its reconciliation evidence | Do not treat payout success as accounting complete |
| Volume spikes | Daily reconciliation by batch and entity during clustered payout periods | Automatic payouts can aggregate multiple transactions, and batches can be large |
Document the path your platform uses from settlement event intake through ledger posting, payout eligibility checks, payout batch execution, and final reconciliation status. The important part is traceability, not forcing one universal order across providers. Each stage should carry an identifier that persists into the General ledger and the Audit trail, so you can trace one funds movement to one entity and one batch outcome.
Treat delayed or non-final responses as normal. Providers document asynchronous flows, and webhook payloads can arrive stale, partial, out of order, or duplicated, so retries need to be duplicate-safe and auditable. Use retry handling that preserves history and prevents duplicate financial impact. If you use idempotency keys, account for limits such as maximum length and retention windows that may be pruned after a period.
Audit trailA retry should fix processing without erasing prior attempts. Keep the original provider event reference, each retry attempt, and the final posting outcome linked in one chain. This matters because providers can redeliver failed webhook events, including repeated attempts after non-2xx responses.
A successful payout status alone does not prove your internal ledger posting step is finished. Payout status and ledger posting can complete at different times, which creates false confidence during close. Before you mark an entity close-ready, confirm that each paid batch has a posted journal and ties to reconciliation evidence. Async payout events can be useful checkpoints for that review.
If volume spikes weekly, consider daily reconciliation by batch and entity during those periods instead of waiting for month end. This is practical because automatic payouts can aggregate multiple transactions, payout schedules can be daily, weekly, monthly, or manual, and batches can be large. Batch-level reconciliation helps catch delayed posting gaps while the operating context is still fresh.
This is where control quality shows up first in real operations. If settlement intake, posting, payout execution, and bank-facing reconciliation do not stay linked, the close will inherit that weakness.
Need the full breakdown? Read What Is a Requisition Order? How Platforms Use Internal Purchase Requests to Control Spend.
To avoid FX surprises, separate management FX views from statutory FX treatment, then make both traceable and repeatable.
Document when translation happens for management reporting and when it happens for statutory reporting under the applicable standard. Under IAS 21, foreign-currency transactions are recorded at initial recognition using the spot rate on the transaction date, and foreign-currency monetary items are translated at period end using the closing rate. Use that statutory logic for close outputs, even if management views use different timing.
Keep transaction currency, accounting currency, and reporting currency tied to the same posting path in the General ledger. This helps reduce unexplained variance during close and review, especially when reports show transaction, accounting, reporting, and translated amounts side by side.
If the output is statutory, translation and revaluation belong in period-end controls. If the output is for operating visibility, earlier translated views may be acceptable, but they should be clearly labeled as management reporting and kept separate from statutory close logic.
Period-end practice requires foreign-currency G/L revaluation with configured rate types such as current, historical, and average, and balances need to be revalued again after exchange-rate changes. If source entity data changes, rerun consolidation. Also avoid closing subsidiary accounts before consolidation is complete.
Verification checkpoint: translated balances should tie from entity books through revaluation and translation settings into Consolidated financial reporting, and the same inputs should produce the same result on rerun.
Related: W-8BEN-E Explained for Platforms: How to Handle Tax Forms from Foreign Business Entities.
Keep tax and compliance evidence on the same entity record used for payout and close decisions. That way finance can explain holds and timing gaps from the Audit trail without reconstructing the story later.
| Artifact or gate | What to record | Timing / eligibility note |
|---|---|---|
| Entity evidence pack | Document, effective date, reviewer, and triggering event in the Audit trail | Triggering events can include onboarding, capability change, or payout release |
W-8BEN-E | Foreign entity status evidence and the receipt or submission path with the linked vendor profile | Track validity through the end of the third succeeding calendar year unless circumstances change |
| Missing required verification data | Paused charges or payouts surfaced in the Exception queue | Required information varies by location, business type, and requested capabilities |
| Certain 1099 capabilities | Payout-disable threshold when required information is not collected and verified | Payouts can be disabled at 600 USD in charges |
| Failed review of updated verified information | Grace-period record for close owners | Record the 14 days grace period |
| Market-specific capabilities | Use "where enabled" wording for conditional features | Cross-border payouts depend on eligibility, and Stripe's W-8 and W-9 collection product is limited to US preview users |
For each Legal entity, define the required evidence pack and exactly where each item lives in the Audit trail. Track the document, effective date, reviewer, and triggering event, such as onboarding, capability change, or payout release. The goal is written support for why activity was allowed or blocked, not just a generic verified status.
Where the payee is a foreign business entity, W-8BEN-E can sit in the entity record because it documents foreign entity status for U.S. withholding and reporting under chapters 3 and 4. It is given to the withholding agent or payer, not filed directly with the IRS, so keep evidence of receipt or submission path with the linked vendor profile. Track validity through the end of the third succeeding calendar year unless circumstances change.
Exception queueIn Stripe Connect, if required verification data is missing or cannot be verified, charges or payouts can be paused, and finance should see that status in the Exception queue. Required information varies by location, business type, and requested capabilities. With certain 1099 capabilities enabled, payouts can be disabled at 600 USD in charges if required information is not collected and verified. If updated verified information fails review, record the 14 days grace period so close owners can explain cash-versus-ledger timing.
Keep conditional features labeled as conditional. Cross-border payouts and related onboarding capabilities depend on eligibility, and Stripe's W-8 and W-9 collection product is limited to US preview users, so use "where enabled" instead of implying universal availability.
Once those artifacts are tied to the entity record, rollout becomes safer because you can prove not just what posted, but why activity was allowed to move.
Use a phased rollout with explicit gates, not a big-bang launch. Smaller go-lives are easier to control, and the first rollout should stay small until one-entity posting is consistently reliable in the General ledger.
| Stage | Primary focus | Gate / evidence |
|---|---|---|
| Phase 1 | Stabilize one-entity posting integrity from settlement through journal entry to payout outcome | Keep the rollout to one Legal entity; if supported, use automatic payouts early and pair them with a payout reconciliation report |
| Phase 2 | Add multi-entity consolidation only after each company's books are stable | Subsidiary-to-consolidated account mapping needs to be clear and complete; unique intercompany accounts by company simplify reconciliation and eliminations |
| Phase 3 | Automate routing from the Exception queue only after manual ownership, due dates, and sign-off are working | The Close calendar should already show owner, close relevance, and evidence location |
| Every phase | Track rollout quality over time | Trend reconciliation pass rate, unresolved Exception queue age, and on-time Close calendar completion |
Start with one Legal entity and prove transaction traceability from settlement through journal entry to payout outcome. Keep this phase focused on explainability from ledger records and the Audit trail, not speed. If your provider supports automatic payouts, use them early to preserve transaction-to-payout linkage, and pair that with a payout reconciliation report so settlement batches can be matched to ledger entries before month end.
Add consolidation only after each company's books are stable on their own. Consolidated financial statements treat the parent and subsidiaries as one economic entity, so subsidiary-to-consolidated account mapping needs to be clear and complete. Different companies can keep different charts of accounts, but the accounts that matter still need explicit mapping. For intercompany activity, unique intercompany accounts by company simplify reconciliation and eliminations.
Automate routing from the Exception queue only after manual ownership, due dates, and sign-off are already working. Your Close calendar should already show owner, close relevance, and evidence location. A financial period close workspace, or equivalent, helps track close status across companies, teams, and owners.
We recommend gating each phase with three trended checks: reconciliation pass rate, unresolved Exception queue age, and on-time Close calendar completion. Require clear pass definitions, visible aging, and documented close tasks, including checklist status and sample transaction-to-journal links.
Use a practical guardrail during rollout. If close sign-off is missed across multiple periods because intercompany breaks were unresolved, pause expansion to new entities until that break pattern is fixed.
Keep payout design in scope while sequencing phases. Gateway routing and split-payment models can change reconciliation workload by adding settlement paths and different reporting shapes. In separate charges and transfers, the platform charge is decoupled from transfers to connected accounts, so update matching logic before adding entities or automating exceptions. If payout design is still moving, pause rollout. Then align with Adaptive Payments for Platforms: How to Split a Single Transaction Across Multiple Payees.
Related reading: What Is a Subscription Lifecycle? How Platforms Manage Trial Active Paused and Churned States.
Multi-entity accounting works as a control chain, not a feature checklist. Keep each company's books reliable in the general ledger. Reconcile intercompany activity, then consolidate with eliminations so group reporting presents the parent and subsidiaries as a single economic entity. If you cannot trace a consolidated number back to entity journals, intercompany treatment, and supporting records, the close may look finished on paper but still be weak in control terms.
No single operating model fits every platform, so choose deliberately and assign ownership early. Management's responsibility for internal control over financial reporting, together with SEC Item 308 requirements, underscores the need for clear accountability. At minimum, make ownership explicit for entity posting, intercompany reconciliation, and consolidation review.
Faster reporting alone is not the signal to expand. A better test is repeatable traceability. Your team should be able to take a material close-pack number, follow its audit trail back to source records, and tie it forward to consolidated presentation with consistent evidence and documented conclusions. That discipline helps keep multi-entity financials trustworthy as complexity increases.
If you want a practical walkthrough of how to connect entity-level ledgers, reconciliation controls, and payout operations in your environment, talk with Gruv.
Multi-entity accounting is managing finances across multiple entities in one organization. For platforms, it means keeping each company's books reliable, then producing consolidated financial statements that present the parent and subsidiaries as a single economic entity. It is different from internal tagging because the accounting spans legally distinct companies.
Multi-location bookkeeping segments activity within the same company, such as by office, region, or department. Multi-entity accounting covers separate companies, which creates consolidation requirements and elimination of internal entity-to-entity activity in group reporting. If you need intercompany eliminations, you are beyond location tracking.
There is no single universal sequence for every platform. A documented workflow typically includes account mapping, data preparation, including translation where needed, consolidation journal posting, and elimination entries. Operationally, the path should stay traceable from transaction activity into each entity general ledger before balances are rolled into group reporting.
There is no universal ranking of close failures. Close quality can break when account mapping, consolidation journals, or elimination entries are incomplete or unsupported. A reliable close should still produce traceable transaction-to-journal evidence and documentation that supports the control assessment.
Before expansion, use documented controls and evidential matter that supports reporting reliability. At a minimum, confirm account mapping, elimination logic, and an audit trail for general-ledger-affecting changes. These controls should be documented so management can support its assessment.
Neither approach is always superior. Choose the model based on operating structure and control requirements for intercompany eliminations and consolidated reporting.
Choose based on operating fit, not a blanket preference. ERP-led consolidation is often simpler when entities already share a chart of accounts and fiscal periods. Ledger-first models can be a fit when transaction-level traceability and posting-change history are primary control requirements.
Farah covers IP protection for creators—licensing, usage rights, and contract clauses that keep your work protected across borders.
Priya specializes in international contract law for independent contractors. She ensures that the legal advice provided is accurate, actionable, and up-to-date with current regulations.
Educational content only. Not legal, tax, or financial advice.
**Start with the business decision, not the feature.** For a contractor platform, the real question is whether embedded insurance removes onboarding friction, proof-of-insurance chasing, and claims confusion, or simply adds more support, finance, and exception handling. Insurance is truly embedded only when quote, bind, document delivery, and servicing happen inside workflows your team already owns.
Treat Italy as a lane choice, not a generic freelancer signup market. If you cannot separate **Regime Forfettario** eligibility, VAT treatment, and payout controls, delay launch.
**Freelance contract templates are useful only when you treat them as a control, not a file you download and forget.** A template gives you reusable language. The real protection comes from how you use it: who approves it, what has to be defined before work starts, which clauses can change, and what record you keep when the Hiring Party and Freelance Worker sign.