CONCLUSIONES SOBRE UNA IMPLANTACIÓN EN SAP DEL NUEVO SISTEMA DE GESTIÓN DEL IVA BASADO EN EL SUMINISTRO INMEDIATO DE INFORMACIÓN DE IVA (SII) QUE ENTRÓ EN VIGOR EN ESPAÑA EL 1 DE JULIO DE 2017 Por José Antonio Salas. 25/08/2017
1. INTRODUCCIÓN El presente documento no tiene otra finalidad que dejar por escrito algunas conclusiones sobre una implantación en SAP del Suministro Inmediato de Información (SII) que entró en vigor en España el 1 de julio de 2017, desde la óptica de la propia empresa en la que se implantó, y más concretamente desde su departamento contable/fiscal. No necesariamente está dirigido a la implantación en SAP, ya que muchas de las conclusiones son válidas para cualquier otro sistema. En el documento, no necesariamente se presentan las cuestiones como verdades absolutas, sino como son percibidas o interpretadas por el autor del mismo. El objetivo es identificar posibles errores o problemas que puedan ayudar a otras empresas en futuras implantaciones del sistema. En cuanto al perfil del que escribe, me definiría como una persona con sólidos conocimientos en el área fiscal, con experiencia en diferentes lenguajes de programación, usuario avanzado de SAP, y en general, autodidacta y muy interesado en todo lo relacionado con la informática. 2. QUIÉNES INTERVIENEN En un proyecto de este tipo es importante que estén bien definidos todos los agentes que participarán en el mismo, tanto por parte de la empresa como por parte de los consultores de SAP encargados de llevarlo a cabo (internos o externos) Lo ideal es que por parte de la empresa estén involucradas, al menos, personas con sólidos conocimientos en fiscalidad y contabilidad, además de ser usuarios avanzados de SAP. Los consultores de SAP deberían tener conocimientos de fiscalidad, o al menos una visión general de la casuística del IVA, así como tener claros algunos conceptos básicos sobre facturación, el devengo y la exigibilidad del impuesto, diferencias entre cuota soportada y deducible, o el ejercicio del derecho a la deducción del IVA. No siempre es fácil conseguir lo anterior, por lo que el principal problema que puede darse en una implantación del SII es, que las personas que intervienen en el proyecto “no siempre hablan el mismo idioma”, lo que puede provocar errores en el enfoque que se dé a temas que puedan ser de importancia. 3. PROCESO LÓGICO EN LA IMPLANTACIÓN DEL SII La implantación del SII en una compañía debería servir no sólo para cumplir con una obligación que viene impuesta, sino como una oportunidad para revisar lo que se venía haciendo, y lo que es más importante, cómo se venía haciendo. No se trata de intentar meter el SII con calzador en la compañía, sino de adaptar en la medida de lo posible los procesos internos de la misma y el propio sistema informático, de forma que éstos se adapten al SII, al tiempo que simplifiquen la forma de trabajar de todos. Sólo así se obtendrán algunos pág. 1
de los beneficios que reporta el SII, en cuanto a la disminución de cargas administrativas y obligaciones de tipo formal. Por ello, un proceso lógico en la implantación sería el siguiente: a) Elaboración del mapa de operaciones de la compañía. Es, probablemente, el paso más importante en la implantación del SII y al que más tiempo habría que dedicarle. Se trata de identificar todos los tipos de operaciones que lleve a cabo la compañía, que se traducirán en una factura, bien sea emitida o recibida, desde una óptica eminentemente fiscal (operaciones sujetas no exentas, sujetas y exentas, no sujetas, AIB, EIB, importaciones, exportaciones, inversión del sujeto pasivo, etc.). El análisis debería extenderse a operaciones no realizadas todavía pero que pudieran llevarse a cabo en el futuro. Esta fase, que deberá ser liderada por el área fiscal de la empresa, tiene como objetivo asociar a cada tipo de operación su propio código de IVA en SAP. Requiere tener altos conocimientos de los desgloses y claves requeridos por el SII. El código de IVA de SAP se define como uno de los elementos más importantes (junto con la serie del documento), ya que será el principal elemento que facilite la correcta “traducción” de cada operación al SII. Tener todas las operaciones bien codificadas implicará tener prácticamente todo el trabajo hecho. Una mala codificación, difusa o que se preste a confusión, provocará problemas en las personas que tengan luego que trabajar con el sistema, y dificultará el trabajo de los consultores de SAP en la implantación del SII. Por ejemplo, en el SII es preciso identificar con ciertas claves a algunos tipos de operación. En el caso de facturas recibidas, es preciso identificar con la clave “12” a aquellas operaciones de arrendamiento de local de negocio. Si sólo dispusiéramos de un código de IVA soportado genérico al 21%, desde el punto de vista del consultor de SAP sería muy complicado saber en qué casos habría que añadir dicha clave al pasar la información al SII. Si creáramos un nuevo código de IVA soportado al 21% sólo para arrendamientos de local, el problema estaría resuelto. Con respecto a la serie de los documentos en SAP, se plantea como otra opción para codificar operaciones o para obtener información de cara a ciertos valores que han de pasarse al SII, aunque menos versátil que el código de IVA. Por ejemplo, es de esperar que las facturas rectificativas tengan su propia serie de facturación, por lo que puede ser configurada para obtener la información necesaria de cara a informar sobre este tipo de operaciones. b) Configuración de SAP. Con el trabajo realizado en el punto anterior, ahora se trata de implementarlo en el sistema. Llegados a este punto, el mayor problema que se puede encontrar es no saber trasladar adecuadamente la información a los consultores de SAP. Otro problema que puede aparecer es, darse cuenta en esta fase de que el mapa de operaciones elaborado no permite trasladar al SII toda la información necesaria, al ser demasiado genérico en algunos tipos de operaciones. Esto obligará a ir modificando “sobre la marcha” el mapa realizado, con el consiguiente riesgo y sensación de improvisación.
pág. 2
4. EL PERIODO IMPOSITIVO EN IVA Aunque pueda parecer incomprensible, es el gran problema de SAP y su principal punto débil. El periodo impositivo en IVA es una de las cosas más importantes, al menos desde el punto de vista del área fiscal de la empresa, pero que no está bien resuelto en SAP. El periodo impositivo asignado a una factura es el que marca el periodo en el que habrá de ser tenida en cuenta a efectos de IVA (inclusión en el modelo 303). Una factura emitida en febrero podrá ser incluida por su emisor en el modelo 303 de enero, del mismo modo que esa misma factura podrá ser incluida por su receptor en el modelo 303 de marzo (tendrá 4 años desde el devengo para ejercer su derecho a la deducción). La casuística es amplia. Pero, ¿cuál es el realmente problema? Pues que en SAP no existe ningún campo que almacene el periodo impositivo, y en muchas ocasiones no se puede calcular a partir de ningún otro. A falta de un campo que contenga la información del periodo impositivo, lo que hace SAP es tomar como referencia otros campos e intentar “calcularlo”, y no siempre existe una fórmula mágica para ello. En resumen, hay más campos de fechas que deben ser informados en el SII, que campos hay en SAP… Normalmente, aunque no siempre, el periodo impositivo coincidirá con el devengo o fecha de operación (campo [VATDATE] de SAP), otras con la fecha de contabilidad [BUDAT], y otras con la fecha de registro [CPUDT]. A veces, los consultores de SAP no perciben la importancia de esto último, por lo que es importante dejarlo muy claro para evitar avanzar en el desarrollo del sistema de forma equivocada. También, las empresas no siempre son conscientes de la importancia de esta cuestión, y el correcto devengo de cada cuota de IVA, así como el periodo en el que se ejercita su deducción en el caso de IVA soportado, es algo que ni se plantea (se declara en el mes que se contabiliza, y punto…) Todo sería más sencillo si existiera un campo específico para el periodo impositivo, pero a día de hoy, desarrollos personalizados aparte, no existe. El problema se complica todavía más en los casos de facturas con devengo de IVA diferido, sobre todo en el supuesto del IVA soportado (ver artículos 75, 76 y 77 de la Ley del IVA). En estos casos, el periodo de liquidación estará en el futuro en el caso de facturas emitidas, y podría estarlo también en el caso de facturas recibidas dependiendo de cuándo se registre la factura en el sistema. En contra de lo que algunos pudieran pensar, todas las empresas reciben facturas de este tipo. ¿Qué empresa no tiene contratados los servicios de teléfono, luz, electricidad, servicio de limpieza, servicios de todo tipo mediante iguala, algún mantenimiento, arrendamiento, etc.? En estos casos, el devengo se produce con la exigibilidad del pago (no antes). Todo lo que sea incluir estas facturas en el modelo 303 con anterioridad a la exigibilidad del pago implicará estar deduciéndose el IVA antes de tiempo (o estar ingresando antes de tiempo el IVA, en el caso del emisor de la factura), además de estar expuestos a contingencias de tipo fiscal. Resumiendo, no existe una fórmula mágica para que SAP coja con garantías el periodo de liquidación de forma correcta para cada factura. Una de las que podría valer con una alta probabilidad de acierto, para facturas recibidas, sería utilizar la fecha mayor entre [VATDATE] y [BUDAT], aunque no siempre. En el caso de facturas emitidas, coger siempre [VATDATE] minimizaría los errores. Todo dependerá también de la forma de contabilizar y qué campos se utilicen. Lo anterior implica que los responsables de la contabilidad de la empresa deben tener muy presente la importancia de identificar correctamente la fecha de operación o devengo en el campo [VATDATE] en el momento de registrar las facturas, siendo conocedores de la casuística existente en cuanto al pág. 3
devengo de cada operación, lo cual, podrá estar en mayor o menor medida automatizado en función de cada empresa. De cara a configurar el periodo impositivo que habrá de informarse en el SII, lo normal será tener que recurrir a un desarrollo personalizado, en función del caso particular de cada empresa. ¡OJO!, este problema no es nuevo, así que no le podemos echar la culpa al SII. La empresa que ya gestionaba mal el periodo impositivo a tener en cuenta en cada factura, probablemente lo seguirá haciendo mal ahora, o aprovechará la ocasión de la implantación del SII para detectarlo y corregirlo en la medida de lo posible. 5. EL FAMOSO CAMPO “DESCRIPCIÓN OPERACIÓN” Se trata de uno de los campos del SII que más polvareda ha levantado desde el inicio. Comentarios ha habido de todo tipo, pero lo cierto es que no deja de ser un campo texto de longitud 500 caracteres para poner, como su propio nombre indica, una descripción de la operación documentada en la factura. Pero, ¿si la factura documenta la venta de 10 artículos, debo identificarlos todos?, ¿con qué grado de detalle hay que describir las operaciones…? Se ha dicho de todo, pero la única cosa que puedo decir al respecto es aplicar el “SENTIDO COMÚN”. También hay que decir que la Agencia Tributaria ha perdido la ocasión para intentar normalizar este campo, creando a veces más confusión todavía. En este campo distinguiría dos aspectos importantes: a) Qué información incluir. b) Dónde obtener dicha información. En cuanto a la información a incluir, debería tratarse de una información útil tanto para la empresa como para la propia Agencia Tributaria. Por ejemplo, incluir una descripción del tipo “Factura según pedido 1234” sólo le aportaría información a la empresa. Sin embargo, incluir “Servicio de limpieza según pedido 1234” sería perfectamente válido. Lo anterior podría implicar tener que definir continuamente cada tipo de servicio u operación, lo que podría ser engorroso, sobre todo con altos volúmenes de facturas. Quizá habría que ir a descripciones más genéricas, tomadas directamente de alguna tabla o asignadas automáticamente según la cuenta contable afectada. Otra forma, quizá la más sencilla y efectiva, es utilizar el código de IVA visto anteriormente, porque su descripción podría aportar la información requerida si se configurara convenientemente. Siguiendo con el ejemplo del código de IVA ya visto al principio de este documento para las operaciones de arrendamiento de local de negocio, bastaría con trasladar dicha descripción a este campo del SII, con lo que resolveríamos el problema de una forma muy sencilla. Igualmente, el contenido de este campo del SII se podría combinar con más información proveniente de otros campos SAP. 6. EL PROBLEMA DE LA TRAZABILIDAD Un problema a la hora de realizar conciliaciones entre la información existente en SAP y la contenida en los libros registro del SII de la AEAT es, que no existe una forma sencilla de relacionar cada factura registrada en el SII con las facturas registradas en SAP, sobre todo en el libro de facturas recibidas.
pág. 4
¿Existe algún campo en el SII que me permita vincular dicho registro de una manera unívoca con algún registro incluido en SAP? Ésta es la pregunta que intentaremos resolver. Sería de gran utilidad que el SII dispusiera de algún campo, al menos opcional, para que la empresa incluyera una referencia de tipo interno, como podría ser el número de documento de SAP [BELNR], de forma que facilitara la conciliación y, por ende, la trazabilidad. Es cierto que la suma de los campos en el SII que hacen referencia en el libro de facturas recibidas al proveedor, fecha expedición, y número de factura, deberían permitirnos llegar a esa información. Pero lo cierto es que los números de factura muchas veces pueden variar al aplicárseles un formato diferente, un mismo proveedor puede estar creado en el maestro de proveedores con distintos códigos, etc. Conclusión, la trazabilidad se termina haciendo compleja. A falta de un campo expresamente creado para ello, una alternativa, no la única, sería la siguiente: Suponiendo que el documento de SAP de la compañía está configurado con una longitud de 10 dígitos, dicho número podría configurarse por los consultores de SAP de forma que se incluyera en las 10 primeras posiciones del campo SII “DESCRIPCIÓN OPERACIÓN”. Así, de cara a hacer conciliaciones una vez descargada la información del SII, bastaría con extraer los 10 primeros dígitos de dicho campo para poderlo asociar con el campo [BELNR] de SAP. 7.
EL PROBLEMA DE LA CUOTA DEDUCIBLE
Otro problema detectado, o eso me parece, es que el campo del SII se ha definido como un campo a nivel de toda la factura, en vez de quedar vinculado a cada cuota de IVA soportado de cada línea de desglose de la factura. Es decir, en una factura que tenga dos líneas de desglose de IVA (por ejemplo, una al 21% y otra al 10%), puesto que el campo se refiere al total de la factura, no podrá saberse qué parte se refiere a la línea del 21% y cuál a la del 10%, pues no siempre toda la cuota soportada es deducible. Lo anterior, más bien, puede parecer un problema para la Agencia Tributaria, que ahora recibe más información, pero de “peor calidad”. Por ejemplo, un desglose como el que se muestra en el siguiente extracto del modelo 390 ya no podrá ser realizado por la Agencia Tributaria, sencillamente porque no va a recibir la información. ¿Tiene sentido que el actual sistema del SII aporte menos información que el que existía anteriormente?
Por otro lado, de cara a hacer conciliaciones de IVA, en el caso de utilizar la información de los libros registro del SII, habrá que tener cuidado con no imputar el total de la a cada línea de desglose de factura, ya que la acabaríamos imputando tantas veces como líneas de desglose haya. pág. 5
8.
OTRAS CONCLUSIONES
Al margen de las ya comentadas en los puntos anteriores, añadiría algunas más: a) Vaya por delante que el que escribe era un SII-escéptico convencido, si se me permite la expresión. Pensaba que lo único que nos iba a traer el SII era una mayor carga de trabajo, prácticamente a cambio de nada. Y, sin embargo, a día de hoy, he de decir que mi opinión ha cambiado. No tanto porque el SII en sí mismo facilite nada o porque ahora no sea necesario presentar algún que otro modelo como el 340, 347 o 390, que también. El beneficio ha venido porque nos ha obligado a cambiar la forma de trabajar, y en contra de la opinión inicial, ha sido para mejor. Se han automatizado muchas operaciones y mejorado varios procesos internos. Obligados en cierto modo por el SII, todo sea dicho. b) Un toque de atención para todos. El SII, en muchos casos, ha destapado en las empresas cosas que se han venido haciendo mal desde hace mucho tiempo. La Ley del IVA y el Reglamento de Facturación no son nuevos y ya estaban ahí antes de que apareciera el SII. c) La forma de actuar de la Agencia Tributaria, en ocasiones errática y cambiando las reglas del juego a cada momento, ha propiciado una situación de caos en algunos momentos en las empresas, que se debía haber evitado. En mi opinión, la definición de muchos campos y la información a facilitar se ha hecho en ocasiones con aparente improvisación. Esto me hace pensar que, a medida que vayan surgiendo algunos problemas u opciones de mejora, lo quieran solucionar aplicando parches cada dos por tres, cuando se podía haber aprovechado para definirlo bien desde el inicio, pensando además en posibles cambios futuros. Por ejemplo, ¿algunos campos que hoy son opcionales, serán obligatorios en un futuro cercano? Si es así, hubiera sido de esperar que estuviese claro desde el principio, porque adaptar los sistemas cuesta tiempo y dinero.
pág. 6
