أسعار الصرف للإقرارات الضريبية: دليل المطوّر للتحويل وفق قواعد IRS وHMRC وضريبة القيمة المضافة الأوروبية

كل نظام متعدد العملات يلتقي بمحاسب في نهاية المطاف. وهو يطرح سؤالاً يبدو بديهياً لكنه ليس كذلك: «ما السعر الذي استخدمتموه لهذه الفاتورة؟» وإذا كانت الإجابة الصادقة هي «أياً كان ما أعادته الـ API بعد ظهر ذلك اليوم، ولم نحتفظ به»، فأنتم أمام مشكلة لن يحلّها أي قدر من الشيفرة النظيفة عند موعد تقديم الإقرار.

ضبط أسعار الصرف للإقرارات الضريبية لا يتعلق كثيراً باختيار السعر الصحيح — فمعظم الجهات التنظيمية متساهلة في ذلك على نحو مفاجئ — بقدر ما يتعلق بقدرتكم على إثبات، بعد سنوات، أيّ سعر استخدمتم، ومن أين جاء، وأنكم طبّقتم القاعدة نفسها على كل معاملة أخرى في الفترة. هذه مسألة نمذجة بيانات، وهي الجزء الذي لا يكتب عنه أحد.

يغطي هذا الدليل ما تشترطه فعلياً كل من IRS وHMRC وتوجيه ضريبة القيمة المضافة الأوروبي، وأخطاء التحويل الخمسة التي تتحول إلى إعادة إصدار للقوائم المالية، ومخطط لقطة سعر يمكنكم تطبيقه هذا الأسبوع.

لا أحد يتفق على «سعر الصرف» الواحد — وهذا هو بيت القصيد

أكثر جملة مفيدة في هذا المجال بأكمله تأتي من IRS نفسها:

«ليس لدى دائرة الإيرادات الداخلية سعر صرف رسمي. وهي تقبل عموماً أي سعر صرف منشور يُستخدم بصورة متسقة».

اقرأوا ذلك مرتين، لأن الصيغة نفسها تتكرر في كل ولاية قضائية تقريباً. فالالتزام نادراً ما يكون استخدم هذا الرقم بعينه، بل هو استخدم مصدراً يمكن الدفاع عنه، واستخدمه بصورة متسقة. والاتساق خاصية في نظامكم، لا في مزوّد الأسعار. فإذا كانت شيفرتكم ترتد بصمت إلى مصدر آخر في عطلات نهاية الأسبوع، تكونون قد خالفتم الشرط دون أن تجلبوا رقماً خاطئاً قط.

الولايات المتحدة: السعر الفوري افتراضاً، والمتوسط السنوي استثناءً

الأساس لدى IRS هو السعر الفوري: «بوجه عام، استخدم سعر الصرف السائد (أي السعر الفوري) عند استلام البند أو دفعه أو استحقاقه». وحيث يتراكم الدخل بانتظام — الرواتب والإيجارات وإيرادات الأعمال المستمرة — تنشر IRS جدول متوسط أسعار صرف العملات السنوي وتوجّه مقدّمي الإقرارات إلى «قسمة المبلغ بالعملة الأجنبية على متوسط سعر الصرف السنوي المنطبق». وحتى آخر تحديث لتلك الصفحة في 24 فبراير 2026، يغطي الجدول السنوات الضريبية من 2021 حتى 2025.

لاحظوا اتجاه هذه العملية. فجدول IRS مُسعَّر بـوحدات العملة الأجنبية مقابل دولار أمريكي واحد، ولذلك تقسمون. وإذا عكستموه بالخطأ فلن تكونوا مخطئين قليلاً، بل ستخطئون بمقدار مربع السعر. وعلى مبلغ بالين الياباني، يعني ذلك نحو أربع مراتب عشرية. والمزيد عن اتجاه السعر أدناه، لأنه أكثر أخطاء التكامل شيوعاً في هذا المجال.

ولإعداد تقارير الوكالات الاتحادية الأمريكية، هناك سلسلة رسمية ثانية: Treasury Reporting Rates of Exchange، وتُنشر ربع سنوياً على FiscalData.Treasury.gov بصيغ CSV وJSON وXML. وتصفها وزارة الخزانة بأنها تعكس «أسعار الصرف التي يمكن للحكومة الأمريكية بموجبها شراء العملات الأجنبية للنفقات الرسمية، وفق ما يبلّغ عنه موظفو الصرف لكل بعثة في آخر يوم عمل من الشهر السابق لتاريخ التقرير المنشور». وإذا ابتعدت الأسعار الحية بنسبة 10% أو أكثر عن سعر منشور، تُصدر الخزانة تعديلاً في منتصف الربع. وواجهة Fiscal Data API مفتوحة ولا تتطلب حساباً أو رمزاً — وهو أمر جدير بالمعرفة إن احتجتم سلسلة مرجعية حكومية المصدر للمطابقة.

المملكة المتحدة: VAT Notice 700 §7.6 له قوة القانون

المملكة المتحدة أكثر تحديداً، والنص ذو الصلة يحمل قوة قانونية بموجب الجدول 6، الفقرة 11 من قانون ضريبة القيمة المضافة لعام 1994. ويمنح VAT Notice 700 الشركات ثلاثة مسارات لتحويل التوريدات بالعملة الأجنبية إلى الجنيه الإسترليني:

1. سعر البيع في السوق البريطانية وقت التوريد. وهذا هو الافتراضي. ينص الإشعار على أن «الأسعار المنشورة في الصحف الوطنية ستكون مقبولة كدليل على الأسعار في الوقت ذي الصلة».
2. سعر الصرف الدوري لـ HMRC، المنشور لأغراض جمركية. ويجوز لكم اعتماده «لجميع توريداتكم أو لجميع التوريدات من فئة أو وصف معيّن». ولا حاجة إلى إخطار مسبق — لكن «بعد اتخاذ هذا الخيار، لا يمكنكم تغييره لاحقاً دون الحصول أولاً على موافقة عبر الكتابة إلى VAT Written Enquiries Team».
3. سعر أو أسلوب تجاري خاص بكم، وهو ما يستلزم طلباً كتابياً. وتقيّم HMRC ما إذا كان السعر «محدداً بالرجوع إلى سوق العملة في المملكة المتحدة»، وما إذا كان «قابلاً للتحقق موضوعياً»، ومدى تواتر تحديثه. والأهم أن «الأسعار الآجلة أو الأساليب المشتقة من الأسعار الآجلة غير مقبولة» — وهو حدّ صارم يستحق الفهم إلى جانب الفرق بين السعر الفوري والسعر الآجل.

أما العبارة التي تحكم طبقة التخزين المؤقت لديكم فهي: «أياً كان السعر أو الأسلوب الذي تعتمدونه، فالسعر المناسب لأي توريد هو السعر السائد وقت التوريد». وقت التوريد، لا وقت إصدار الفاتورة، ولا وقت الدفع، وبالتأكيد ليس وقت مهمتكم الليلية المجمّعة.

وإذا اخترتم المسار 2، فالآليات ودودة للأنظمة إلى حد مريح. تنشر HMRC الأسعار الشهرية في الخميس قبل الأخير من كل شهر؛ وهي تنطبق على الشهر التقويمي التالي وتمثل الأسعار كما في منتصف نهار اليوم السابق للنشر. وتوجد الملفات على عنوان URL يمكن التنبؤ به — ولاحظوا أن رقم الشهر لا يُستكمل بصفر بادئ:

https://www.trade-tariff.service.gov.uk/exchange_rates/view/files/monthly_csv_2026-9.csv
https://www.trade-tariff.service.gov.uk/exchange_rates/view/files/monthly_xml_2026-9.xml

جلب واحد شهرياً، وتخزين مؤقت طوال الشهر، وعندها يصبح كل تحويل لضريبة القيمة المضافة البريطانية في تلك الفترة قابلاً لإعادة الإنتاج من ملف يمكنكم تسليمه للمفتش.

الاتحاد الأوروبي: المادة 91 من توجيه ضريبة القيمة المضافة

بالنسبة للتوريدات داخل الاتحاد الأوروبي، تحدد المادة 91(2) من توجيه المجلس 2006/112/EC القاعدة بأنها «آخر سعر بيع مسجّل، وقت استحقاق ضريبة القيمة المضافة، في سوق أو أسواق الصرف الأكثر تمثيلاً في الدولة العضو المعنية، أو سعر يُحدَّد بالرجوع إلى ذلك السوق أو تلك الأسواق».

وسيكون تطبيق ذلك صعباً عبر 27 دولة عضواً، ولذلك يضيف التوجيه مخرجاً عملياً: على الدول الأعضاء «أن تقبل بدلاً من ذلك استخدام آخر سعر صرف ينشره البنك المركزي الأوروبي وقت استحقاق الضريبة». ويجري التحويل بين عملتين غير اليورو «باستخدام سعر صرف كل عملة مقابل اليورو» — أي عبر تقاطع اليورو بدلاً من تسعير الزوج مباشرة. وللدول الأعضاء أن تشترط إخطارها بأنكم تمارسون هذا الخيار.

أما بالنسبة للواردات، فتحيل المادة 91(1) إلى القواعد الجمركية لاحتساب القيمة للأغراض الجمركية — سعر مختلف فعلاً، في تاريخ مختلف فعلاً، ضمن الدفتر نفسه. وإذا كان نظامكم يتعامل مع «ضريبة القيمة المضافة الأوروبية» كقاعدة تحويل واحدة، فهو مخطئ بالفعل.

ما يقوم عليه كل ذلك: IAS 21

تستند القواعد الضريبية إلى سياستكم المحاسبية، وبالنسبة للمعدّين وفق المعايير الدولية فتلك السياسة هي IAS 21. وأربعة أحكام تنجز معظم العمل:

• تُثبَت المعاملة بالعملة الأجنبية مبدئياً بـالسعر الفوري في تاريخ المعاملة (IAS 21.21).
• يُسمح بالسعر المتوسط كتبسيط، لكن فقط «ما دامت أسعار الصرف لا تتقلب بصورة جوهرية» (IAS 21.22). وهذا شرط، لا وضع افتراضي — وهو البند الذي يسقط بهدوء في ربع سنة متقلب.
• تُعاد ترجمة البنود النقدية بـسعر الإقفال في تاريخ التقرير (IAS 21.23).
• البنود غير النقدية المقاسة بالتكلفة التاريخية تبقى بسعر تاريخ المعاملة ولا يُعاد ترجمتها.

وتصل مبادئ US GAAP إلى استنتاجات مشابهة إلى حد بعيد بموجب ASC 830. والنتيجة العملية للمطوّر هي أن معاملة واحدة قد تستلزم بصورة مشروعة سعرين أو ثلاثة أسعار مختلفة خلال حياتها — واحد عند الإثبات، وواحد عند إقفال الفترة، وواحد عند التسوية — ويجب أن يتسع مخططكم لها جميعاً. ويشرح دليلنا حول إدارة مخاطر العملة للشركات ما تعنيه الأرباح والخسائر الناتجة من الناحية التجارية.

خمسة أخطاء تحويل تتحول إلى إعادة إصدار للقوائم المالية

1. اتجاه السعر

base=USD&symbols=EUR يعيد اليورو مقابل الدولار. وbase=EUR&symbols=USD يعيد الدولار مقابل اليورو. وجدول IRS السنوي هو عملة أجنبية مقابل USD، فتقسمون؛ أما استجابة Finexly بـ base=EUR فهي USD مقابل EUR، فتضربون. كلاهما صحيح؛ لكن خلطهما ليس كذلك.

والحل ممل وفعّال: لا تسمّوا عموداً باسم rate أبداً. سمّوه quote_per_base، واجعلوا الاتجاه لا لبس فيه داخل المخطط لا في تعليق.

2. إعادة الاستعلام بدلاً من إعادة التشغيل

تدقيق في 2029 يسأل عن معاملة من 2026. فإذا كانت شيفرة التقارير لديكم تستدعي endpoint حياً وقت توليد التقرير، فإن تشغيلين للتقرير نفسه ينتجان رقمين مختلفين. السعر المطبَّق على معاملة هو حقيقة تخص تلك المعاملة، لا عملية بحث — فاحفظوه لحظة التحويل. ونقاط endpoint التاريخية موجودة لـالتعبئة الرجعية والمطابقة، لا كبديل عن التخزين؛ راجعوا دليل API أسعار الصرف التاريخية للاطلاع على أنماط التعبئة الرجعية.

3. المتوسط حيث يُشترط السعر الفوري

المتوسطات الشهرية مريحة ومسموح بها غالباً، لكن IAS 21.22 يعلّق عليها شرطاً، والمعاملات غير المتكررة تتطلب عموماً سعر تاريخ المعاملة بموجب إرشادات IRS. احفظوا الأسلوب إلى جانب السعر لتتمكنوا من الإجابة عن «لماذا هذا الرقم؟» دون تنقيب أثري.

4. الأيام المفقودة

عطلات نهاية الأسبوع والأعياد الوطنية والأيام غير المشمولة بنظام TARGET لا سعر منشوراً لها. وكل نظام يحتاج قاعدة صريحة — عادةً «آخر سعر منشور في التاريخ أو قبله» — ويحتاج إلى تسجيل أي قاعدة انطبقت. فالارتداد الصامت لا يمكن تمييزه عن خلل برمجي بعد ستة أشهر. وهذا يتداخل مباشرة مع ممارسات التخزين المؤقت ومعالجة الأخطاء.

5. الدقة والتقريب

احفظوا خانات عشرية أكثر مما تعرضون، وقرّبوا مرة واحدة بالضبط، عند خطوة العرض أو القيد النهائية. فالتقريب عند كل خطوة وسيطة عبر بضعة آلاف من الفواتير ينتج فجوة مطابقة يشقّ شرحها ويستحيل عكسها. وقد تناولنا الحساب بالتفصيل في تقريب العملات والخانات العشرية.

صمّموا لقطة السعر، لا عملية البحث عن السعر

تنهار المشكلة برمّتها إذا توقفتم عن التفكير في التحويل كاستدعاء دالة وبدأتم التفكير فيه كسجل غير قابل للتغيير. وإليكم مخططاً بحدّه الأدنى يستوفي كل المتطلبات التي نوقشت أعلاه:

CREATE TABLE fx_rate_snapshot (
    id                BIGSERIAL PRIMARY KEY,
    transaction_id    BIGINT      NOT NULL,
    -- direction is in the name, not in a comment
    base_currency     CHAR(3)     NOT NULL,   -- e.g. 'EUR'
    quote_currency    CHAR(3)     NOT NULL,   -- e.g. 'USD'
    quote_per_base    NUMERIC(20,10) NOT NULL,

    rate_date         DATE        NOT NULL,   -- the date the rate APPLIES to
    method            TEXT        NOT NULL,   -- 'spot' | 'monthly_period' | 'yearly_average'
    fallback_applied  TEXT,                   -- 'previous_business_day' | NULL

    source            TEXT        NOT NULL,   -- 'finexly' | 'hmrc_monthly' | 'irs_yearly'
    source_reference  TEXT,                   -- file name, request id, or table year
    retrieved_at      TIMESTAMPTZ NOT NULL,   -- when WE obtained it

    amount_base       NUMERIC(20,4) NOT NULL,
    amount_quote      NUMERIC(20,4) NOT NULL,

    created_at        TIMESTAMPTZ NOT NULL DEFAULT now()
);

-- one authoritative conversion per transaction per purpose
CREATE UNIQUE INDEX ux_fx_snapshot_txn_method
    ON fx_rate_snapshot (transaction_id, method, rate_date);

ثلاثة أعمدة تحمل معظم عبء التدقيق. فـrate_date هو التاريخ الذي ينطبق عليه السعر، وهو منفصل عمداً عن retrieved_at، أي لحظة حصولكم عليه — فسعر يوم 13 مارس جرى جلبه أثناء تعبئة رجعية في سبتمبر أمر مشروع تماماً، وزوج الطوابع الزمنية يقول ذلك بصدق. وfallback_applied يحوّل قاعدة عطلة نهاية الأسبوع لديكم من سلوك خفي إلى دليل مسجَّل.

ولاحظوا أن الصفوف لا تُحدَّث أبداً. فإذا صُحِّح سعر، أدرجوا صفاً جديداً يحل محل القديم. فمسار التدقيق الذي يمكنكم تحريره ليس مسار تدقيق.

جلب سعر تاريخي يمكن الدفاع عنه

للحصول على سعر تاريخ المعاملة، اطلبوا التاريخ المحدد بدلاً من التاريخ الحالي:

curl "https://api.finexly.com/v1/historical?date=2026-03-13&base=EUR&symbols=USD" \
  -H "Authorization: Bearer YOUR_API_KEY"

{
  "base": "EUR",
  "date": "2026-03-13",
  "rates": {
    "USD": 1.0842
  }
}

مع base=EUR، تكون القيمة دولارات مقابل اليورو — لذا تتحول فاتورة بقيمة 10,000 يورو إلى 10,842.00 دولار بالضرب. وإليكم نمط «اللقطة عند الكتابة» بلغة Python، بما في ذلك الارتداد الخاص باليوم المفقود والحقول التي يتوقعها المخطط أعلاه:

import requests
from datetime import date, timedelta
from decimal import Decimal, ROUND_HALF_UP

API = "https://api.finexly.com/v1/historical"
HEADERS = {"Authorization": "Bearer YOUR_API_KEY"}


def fetch_rate(base: str, quote: str, on: date, max_lookback: int = 5):
    """Return (quote_per_base, rate_date, fallback) for a given date.

    Walks back to the most recent published rate if `on` is a weekend
    or a market holiday, and reports which day it actually landed on.
    """
    for offset in range(max_lookback + 1):
        d = on - timedelta(days=offset)
        r = requests.get(
            API,
            params={"date": d.isoformat(), "base": base, "symbols": quote},
            headers=HEADERS,
            timeout=10,
        )
        r.raise_for_status()
        rates = r.json().get("rates", {})
        if quote in rates:
            fallback = "previous_business_day" if offset else None
            return Decimal(str(rates[quote])), d, fallback

    raise LookupError(f"No {base}/{quote} rate within {max_lookback} days of {on}")


def convert_for_filing(amount_base, base, quote, transaction_date):
    """Convert once, and return everything an auditor will ask for."""
    rate, rate_date, fallback = fetch_rate(base, quote, transaction_date)
    amount = Decimal(str(amount_base))
    converted = (amount * rate).quantize(Decimal("0.01"), rounding=ROUND_HALF_UP)

    return {
        "base_currency": base,
        "quote_currency": quote,
        "quote_per_base": rate,
        "rate_date": rate_date.isoformat(),
        "method": "spot",
        "fallback_applied": fallback,
        "source": "finexly",
        "amount_base": amount,
        "amount_quote": converted,
    }


snapshot = convert_for_filing(10000, "EUR", "USD", date(2026, 3, 13))
print(snapshot["amount_quote"], snapshot["rate_date"], snapshot["fallback_applied"])
# -> 10842.00 2026-03-13 None

تحوّل الدالة وتوثّق في النفس نفسه. وأياً كانت طبقة التخزين لديكم، اكتبوا ذلك القاموس إليها قبل أن يرى أي مكوّن لاحق الرقم. وتؤتي الانضباطية نفسها ثمارها في الفوترة متعددة العملات وفوترة SaaS وكشوف الرواتب العابرة للحدود — وكلها تنتهي في الإقرار الضريبي نفسه.

المطابقة مع السعر الرسمي المنشور

بالنسبة لضريبة القيمة المضافة البريطانية عبر المسار 2، اسحبوا ملف HMRC الشهري مرة كل شهر واحفظوه كمصدر للحقيقة لتلك الفترة:

import csv, io, requests
from datetime import date

def hmrc_monthly_rates(year: int, month: int) -> dict:
    """HMRC monthly rates for VAT/customs. Note: month is NOT zero-padded."""
    url = (
        "https://www.trade-tariff.service.gov.uk/exchange_rates/view/files/"
        f"monthly_csv_{year}-{month}.csv"
    )
    resp = requests.get(url, timeout=15)
    resp.raise_for_status()

    reader = csv.DictReader(io.StringIO(resp.text))
    # Don't hard-code the header text: find the ISO-4217 code column by shape.
    code_col = next(
        c for c in reader.fieldnames if "code" in c.strip().lower()
    )
    return {
        row[code_col].strip(): row
        for row in reader
        if row.get(code_col) and len(row[code_col].strip()) == 3
    }

ثم شغّلوا فحص انحراف دورياً: قارنوا كل لقطة مخزّنة بالسعر الرسمي لفترتها، وضعوا علامة على أي شيء يقع خارج حدّ تسامح اخترتموه عن قصد. والاختلافات الطفيفة بين سعر السوق وسعر إداري منشور متوقعة ومقبولة عادةً — لكنكم تريدون معرفة حجم الفجوة قبل أن يحسبها لكم المفتش. وإذا كنتم تربطون هذا بدفتر أستاذ، فإن ملاحظاتنا حول التكامل مع برامج المحاسبة وحول مصادر بيانات واجهات API لأسعار الصرف تغطي أسئلة المنشأ التي تأتي تالياً.

قائمة تحقق ما قبل تقديم الإقرار للبيانات متعددة العملات

1. لكل مبلغ محوَّل سعر مخزَّن. ولا يعيد أي تقرير احتساب تحويل تاريخي وقت التشغيل.
2. اتجاه السعر لا لبس فيه في أسماء الأعمدة، لا في التوثيق.
3. rate_date وretrieved_at حقلان منفصلان، وكلاهما مملوء.
4. قاعدة اليوم المفقود صريحة ومسجَّلة، لا محاولة إعادة ضمنية.
5. أسلوب واحد لكل فئة من المعاملات، مطبَّق بصورة متسقة على الفترة بأكملها — وهو المتطلب القانوني الفعلي في الولايات المتحدة والمملكة المتحدة معاً.
6. التقريب يحدث مرة واحدة، عند الخطوة النهائية، بوضع موثَّق.
7. صفوف اللقطات للإضافة فقط. فالتصحيحات تحل محلّ السابق ولا تكتب فوقه أبداً.

اعملوا على هذه السبع، ويتوقف سؤال المحاسب عن كونه مخيفاً. وتصبح الإجابة استعلاماً.

الأسئلة الشائعة

ما سعر الصرف الذي تشترطه IRS للإقرارات الضريبية؟ لا سعر بعينه. تذكر IRS صراحةً أنه «ليس لديها سعر صرف رسمي» وأنها «تقبل عموماً أي سعر صرف منشور يُستخدم بصورة متسقة». والافتراضي هو السعر الفوري السائد عند استلام البند أو دفعه أو استحقاقه؛ أما بالنسبة للدخل المتراكم بانتظام فتنشر IRS جدول متوسط سنوي وتوجّه مقدّمي الإقرارات إلى قسمة المبلغ الأجنبي على السعر المدرج.

هل يمكنني استخدام API للعملات بدلاً من أسعار HMRC المنشورة لضريبة القيمة المضافة؟ نعم، ضمن حدود. يجعل VAT Notice 700 §7.6 سعرَ البيع في السوق البريطانية وقت التوريد هو الافتراضي، لذا يناسب سعرٌ من API قائم على السوق ذلك المسار شريطة تطبيقه بصورة متسقة. وسعر HMRC الدوري بديل صريح يمكنكم اعتماده دون إخطار مسبق — لكن بعد اعتماده لا يمكنكم العودة دون موافقة كتابية. أما السعر أو الأسلوب الذي يقع خارج المسارين فيتطلب طلباً كتابياً، والأسعار الآجلة غير مقبولة.

هل يلزمني تخزين سعر الصرف، أم يمكنني البحث عنه لاحقاً مرة أخرى؟ خزّنوه. فالسعر المخزَّن يجعل التحويل قابلاً لإعادة الإنتاج؛ أما إعادة الاستعلام فتجعله حساباً جديداً قد لا يطابق الإقرار الذي قدّمتموه بالفعل. وتخزين السعر وتاريخه ومصدره ولحظة استرجاعه هو ما يحوّل الرقم إلى دليل.

ما السعر الذي ينبغي استخدامه إذا وقع تاريخ المعاملة في عطلة نهاية أسبوع أو عيد؟ لا يوجد سعر منشور ليوم غير تداولي، لذا تحتاجون إلى قاعدة معلنة — وأكثرها شيوعاً آخر سعر منشور في تاريخ المعاملة أو قبله. والأهم من اختيار القاعدة أن تكون موثَّقة ومطبَّقة بصورة موحّدة ومسجَّلة على كل صف متأثر.

كم خانة عشرية ينبغي تخزينها للأغراض الضريبية؟ خزّنوا الدقة الكاملة التي يعيدها مزوّدكم — وست إلى عشر خانات عشرية عرضُ عمود معقول — وقرّبوا فقط عند القيد أو العرض. فالتقريب المبكر والمتكرر هو السبب المعتاد لفجوات المطابقة التي لا يستطيع أحد تتبعها.

هل يستوفي سعر البنك المركزي الأوروبي متطلبات ضريبة القيمة المضافة الأوروبية؟ تلزم المادة 91(2) من توجيه ضريبة القيمة المضافة الدولَ الأعضاء بقبول آخر سعر للبنك المركزي الأوروبي منشور وقت استحقاق الضريبة، على أن تمرّ التحويلات بين العملات عبر سعر كل عملة مقابل اليورو. وتشترط بعض الدول الأعضاء إخطارها باستخدامكم هذا الخيار، أما الواردات فتخضع لقواعد التقييم الجمركي بدلاً من ذلك.

اجعلوا أسعاركم جاهزة للتدقيق

هل أنتم مستعدون لدمج أسعار الصرف الآنية والتاريخية في مشروعكم؟ احصلوا على مفتاح Finexly API المجاني — دون الحاجة إلى بطاقة ائتمان. ابدأوا بـ 1,000 طلب مجاني شهرياً وارتقوا مع نموّكم. راجعوا توثيق API للاطلاع على المرجع الكامل لـ endpoint التاريخي، وجرّبوا محوّل العملات للفحوصات المفردة، وقارنوا واجهات API للعملات إن كنتم تقيّمون المزوّدين، واطّلعوا على خطط الأسعار عندما ينمو حجم إقراراتكم.

هذه المقالة دليل تقني للمطورين الذين يبنون أنظمة متعددة العملات. وهي ليست استشارة ضريبية — تأكدوا من سياسة التحويل لديكم مع مستشار مؤهل في كل ولاية قضائية تقدّمون فيها إقراراتكم.