Source: https://www.scribd.com/document/4767720/ManualFacturaElectronica
Timestamp: 2017-02-20 01:40:53
Document Index: 347771789

Matched Legal Cases: ['Artículo 6', 'artículo 2', 'artículo 2', 'artículo 2', 'artículo 164', 'artículo 9', 'artículo 88', 'artículo 88', 'artículo 9', 'artículo 88', 'artículo 9', 'artículo 31', 'artículo 88', 'artículo 9', 'artículo 18', 'artículo 2', 'artículo 2', 'artículo 88', 'artículo 9', 'artículo 3', 'artículo 11']

BrowseInterestsBiography & MemoirBusiness & LeadershipFiction & LiteraturePolitics & EconomyHealth & WellnessSociety & CultureHappiness & Self-HelpMystery, Thriller & CrimeHistoryYoung AdultBrowse byBooksAudiobooksNews & MagazinesSheet MusicBrowse allUploadSign inJoinEdición RevisadaLa factura electrónica
4.1.Cómo se conservan electrónicamente facturas recibidas en papel
Aunque normativamente se prevé la conservación electrónica de facturas, por la condición de
que las facturas deban estar disponibles para la inspección tributaria en el formato original en el que fueron recibidas, hasta muy recientemente se entendía que dicha conservación electrónica solo aplica a las facturas remitidas electrónicamente. La Agencia Tributaria (sección
factura electrónica) está promoviendo actualmente el concepto de Digitalización Certificada como el proceso en que, partiendo de una factura en papel, se genera una imagen digital firmada electrónicamente a la que se le aplica la presunción de tener el mismo
valor probatorio que la factura original, de forma semejante a la de una compulsa electrónica, permitiendo, por ello destruir la propia factura original en papel. Para que se dé por buena la presunción descrita, será preciso utilizar
dispositivos auditados (lo que, en definitiva, supone una modalidad de homologación) así como disponer de un informe de auditoría del proceso de digitalización. Para garantizar que los documentos así digitalizados cumplen de forma íntegra las condiciones de autenticidad, se recomienda utilizar la modalidad de firma electrónica ES-X-L, descrita anteriormente como firma completa, ya que quien deba verificar la firma no debe preocuparse de encontrar el mecanismo de comprobación de validez, que puede ser diferente para cada prestador. Debe tenerse en cuenta que solo en España existen más de 20 sistemas de certificación, cada uno de los cuales tiene su propio mecanismos de verificación. Si se emplea un sistema OCR (Optical Character Recognition) el sistema puede reconocer letras y números y superponerlos en una capa del fichero, de forma que se simplifica la indexación y la búsqueda de documentos. Si además la factura se ha impreso según una plantilla acordada, el OCR permitirá codificar la factura en el formato estándar UBL (Promovido por el consorcio internacional Oasis), facilitando también la inserción del contenido de la factura en el sistema informático y su tratamiento más o menos automatizado. Por este motivo se recomienda la
adopción de modelos de factura concretos por parte de los emisores. Así, incluso cuando se emite una factura en papel se puede estar facilitando la labor al receptor. Para minimizar el número de modelos posibles y mejorar las probabilidades de reconocimiento óptico, existen varias iniciativas. Una de ellas es UNeDocs, de las Naciones Unidas, pensada para facturas complejas utilizas en intercambios de importación y exportación, donde seguramente es más necesaria por las dificultades añadidas por los múltiples idiomas utilizados en un tránsito de mercancías. Otra iniciativa es la Factura Normalizada de ASIMELEC. La factura normalizada es una plantilla que facilita la emisión de facturas, y su posible digitalización por el receptor. Existen 3 niveles de facturas normalizadas, dependiendo de la complejidad de la factura y del tipo de contenido. A, B, C. La factura normalizada facilita la acción del OCR cuando se digitaliza por parte del obligado tributario receptor. Una variante D de la factura normalizada incluye un código PDF-417 de la factura en formato UBL en la última hoja de la factura, para facilitar la conversión a formato electrónico. Esta modalidad no lleva firma electrónica, puesto que es una factura expedida en papel. Otras modalidades de formatos bidimensionales son posibles.
4.2.Cómo se conservan en papel las facturas recibidas electrónicamente
Aunque existe la posibilidad de almacenar facturas electrónicas en papel mediante un código de barras PDF-417, es posible otro mecanismo alternativo. Si existen aplicaciones informáticas que gestionen un repositorio de facturas
emitidas o recibidas, según corresponda, junto con la firma electrónica generada o verificada, proporcionando un código de autenticación de mensajes asociado a cada factura, cabe la posibilidad de identificar las facturas mediante dicho código. Este código permitirá el acceso al documento asociado existente en el repositorio y garantizará, al que accede, que la factura cumple con los requisitos contemplados en la normativa.
¬ Ejemplo de esquema de generación de código de recuperación de facturas
Con los datos de la factura electrónica se genera un código identificador único susceptible de ser introducido en la copia papel de la factura para su posterior localización y recuperación.
Aunque existe la posibilidad de almacenar facturas electrónicas en papel mediante un código de barras, es posible otro mecanismo alternativo
Por tanto, una factura transcrita al papel con este código es válida, siempre que se mantenga dicho repositorio donde exista la factura y su firma electrónica, exista un mecanismo de verificación de la firma en el repositorio y se pueda acceder de forma completa a la factura mediante dicho código electrónico de autenticación. Esta modalidad de gestión de facturas electrónicas en papel está prevista en el Artículo 6 de la Orden EHA-962/2007.
5.1.Formatos de factura electrónica
El formato contenedor de la factura, esto es, aquel fichero donde se almacenan los datos que conforman la factura antes de aplicarles la firma electrónica, desde un punto de vista
meramente legal, en principio no tiene ninguna relevancia. Podría tratarse de un PDF, un archivo RTF, un documento Excel, texto plano, HTML, XML, etc. Cualquier formato empleado es válido siempre que posteriormente sea firmado electrónicamente para dotarlo de validez legal.
<?xml version=”1.0” encoding=”UTF-8”?> <Invoice xmlns:cbc=”urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents1.0” xmlns:cac=”urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents1.0” xmlns:cur=”urn:oasis:names:specification:ubl:schema:xsd:CurrencyCode-1.0” xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance”> <ID>1</ID> <GUID>7f000001106832df692100000a45e2d8</GUID> <cbc:IssueDate/> <InvoiceCurrencyCode>840</InvoiceCurrencyCode> <LineItemCountNumeric>2</LineItemCountNumeric> <cac:OrderReference> <cac:BuyersID><![CDATA[B82568718]]></cac:BuyersID> <cac:SellerID><![CDATA[B82568718]]></cac:SellerID> <DocumentStatusCode><![CDATA[]]></DocumentStatusCode> </cac:OrderReference> <cac:BuyerParty> <cac:Party> <cac:PartyName><cbc:Name><![CDATA[Paul Klein]]></cbc:Name></cac:PartyName> <cac:Address> <ID>7f000001106709e1bda10000ec419d26</ID> <cbc:PostBox></cbc:PostBox> <cbc:StreetName><![CDATA[Bulbury]]></cbc:StreetName> <cbc:AdditionalStreetName><![CDATA[ST]]></cbc:AdditionalStreetName> <cbc:BuildingName><![CDATA[]]></cbc:BuildingName> <cbc:BuildingNumber><![CDATA[80]]></cbc:BuildingNumber> <cbc:CityName><![CDATA[]]></cbc:CityName> <cbc:PostalZone></cbc:PostalZone> <cbc:CountrySubentity><![CDATA[]]></cbc:CountrySubentity> <cbc:CountrySubentityCode></cbc:CountrySubentityCode> <cbc:AddressLine><![CDATA[]]></cbc:AddressLine> <Country><![CDATA[]]></Country> </cac:Address> </cac:Party> <cac:AccountsContact> <cbc:Name><![CDATA[]]></cbc:Name> <cbc:Telephone><![CDATA[]]></cbc:Telephone> </cac:AccountsContact> </cac:BuyerParty> <cac:SellerParty> <cac:Party> <cac:PartyName><cbc:Name><![CDATA[Know Gate Ltd.]]></cbc:Name></cac:PartyName> <cac:Address> <ID>7f0000011067057c4ef100008c688128</ID> <cbc:StreetName><![CDATA[Wesleyan]]></cbc:StreetName> <cbc:AdditionalStreetName><![CDATA[ST]]></cbc:AdditionalStreetName> <cbc:BuildingName><![CDATA[]]></cbc:BuildingName> <cbc:BuildingNumber><![CDATA[107]]></cbc:BuildingNumber> <cbc:CityName><![CDATA[Boston]]></cbc:CityName> <cbc:PostalZone></cbc:PostalZone> <cbc:CountrySubentity><![CDATA[MA]]></cbc:CountrySubentity> <cbc:CountrySubentityCode></cbc:CountrySubentityCode> <cbc:AddressLine><![CDATA[]]></cbc:AddressLine> <Country><![CDATA[United States]]></Country> </cac:Address> </cac:Party> <cac:AccountsContact>
¬ Extracto de factura en XML
El formato de la factura dependerá por tanto de las necesidades de la aplicación y, de forma muy significativa, de la estandarización del sistema empleado. El XML permite definir nombres de campos y asignarles significados. Cuando los ordenadores de dos interlocutores comparten los mismos nombres y las mismas definiciones, pueden intercambiarse información significativa para ambos mediante XML y actuar en consecuencia. Existen grupos de trabajo para dar uniformidad a las definiciones de las facturas en XML, que se agrupan en un organismo de impulso a la estandarización que se denomina OASIS. Las variantes específicas son ebXML (Electronic Business XML) y UBL (Universal Business Language), que salvo matices (la capa de comunicaciones que gestiona cada uno) se refieren al mismo grupo de estándares. El formato que actualmente cumple de una manera más efectiva con los requerimientos de la facturación electrónica es el XML UBL (Universal Business Language), debido a que se trata de un formato de intercambio basado en ebXML especialmente diseñado para garantizar la interoperabilidad de las relaciones comerciales mediante la utilización de una biblioteca de esquemas con los datos y documentos de uso más frecuente en el tráfico mercantil, como los albaranes y facturas. UBL permite también un diseño modular adaptable a los requerimientos de cada usuario, lo que lo convierte en un formato de una gran flexibilidad. La sintaxis XML se define en http://www.w3.org/XML/ La firma electrónica básica en XML se define en http://www.w3.org/Signature/ La firma electrónica avanzada se define en http://uri.etsi.org/01903/v1.2.2/ts_101903v010202p.pdf La estandarización de su formato está en http://www.ietf.org/rfc/rfc3275.txt El ebXML se mantiene en http://www.ebxml.org/ El UBL se mantiene en http://www.oasisopen.org/committees/tc_home.php?wg_abbrev=ubl
¬ Esquema CCI
Sólo hasta la versión 2 (inclusive versiones menores). A partir de la versión 3 el estándar se desarrollará en el marco de las Naciones Unidas. En España, el CCI (Centro de Cooperación Interbancaria) ha desarrollado un conjunto de recomendaciones para codificar tanto la factura electrónica como la firma electrónica. El formato está basado en XML y recoge todos los requisitos de la normativa española, en particular el RD-1496/2003 y el RD-87/2005. En base a este formato, a iniciativa de la Agencia Tributaria y del Ministerio de Industria, Turismo y Comercio se publica el formato facturae que dispone de un portal en http://www.facturae.es y se oficializa por la ORDEN PRE/2971/2007, de 5 de octubre, sobre la expedición de facturas por medios electrónicos cuando el destinatario de las mismas sea la Administración General del Estado u organismos públicos vinculados o dependientes de aquélla y sobre la presentación ante la Administración General del Estado o sus organismos públicos vinculados o dependientes de facturas expedidas entre particulares. (BOE n. 247 de 15/10/2007) Este formato será de obligado cumplimiento en España para facturas remitidas a las administraciones públicas y evolucionará de forma que pueda ser considerado la personalización para España de los estándares internacionales y su guía de implantación.
La mayor parte de los formatos internacionales de codificación de factura están experimentando en los últimos tiempos una sensibilización hacia cierto “ecumenismo” auspiciado por las Naciones Unidas. La base de los elementos de acuerdo y convergencia es la Librería de Componentes Centrales Comunes (Common Core Components Library), disponible en http://www.unece.org/cefact/codesfortrade/cosdes_index.htm que procede de la especificación Técnica de Componentes Centrales (CCTS, Core Components Technical Specification), así como la Especificación de Requisitos de Negocio de la Factura Intersectorial (Business Requirements Specification (BRS) of the Cross Industry Invoice) disponible en: http://www.disa.org/cefact-groups/tbg/wg/tbg1_main.cfm También es relevante la definición de Reglas de Denominación y de Diseño XML (XML Naming and Design Rules), que en la actualidad se han publicado bajo el auspicio de UN/CEFACT en su versión 2.0 (http://webster.disa.org/cefact-groups/atg). En el sector de gran consumo, que durante muchos años ha estado respaldando el formato EDIFACT (a través de las redes EANCOM, AECOM, en su versión española) promueve un formato XML, que podría ser el preferido en la migración desde
EDIFACT, pero todavía no se ha adoptado de forma amplia. Se encuentra información sobre este formato en: http://www.gs1.org/productssolutions/ecom/xml/ http://www.ean-int.org/productssolutions/ecom/xml/implementation/guide/index.html Para quienes deben prever la posibilidad de desarrollar interfaces de conversión de varios formatos, las prioridades recomendadas son: • facturae • UBL (si tiene clientes internacionales) • GS1-XML (para sus clientes del sector de gran consumo) En todo caso, hay que dar la bienvenida a una nueva iniciativa de estandarización en el marco de CEN (Comité Europeo de Normalización) que acoge al eInvoice Workshop cuya información está accesible en http://www.cenorm.be/cenorm/businessdomains/businessdomains/isss/activity/wseinvoice.asp
5.2.Formatos de firma
Formatos de firma especiales: firma fechada y validada
Además de los tipos de firma simple, avanzada y reconocida (qualified electronic signature en inglés) que establecen tanto la Directiva como la Ley de Firma Electrónica, desde el punto de vista técnico, se han definido
en el marco del Comité Europeo de Normalización otros tipos de firma electrónica que son esenciales para facilitar su uso en diferentes contextos. La firma básica es aquella que recoge los elementos esenciales de la firma electrónica: el resumen del documento firmado (hash), el certificado del firmante asociado a la clave privada con la que se firma y el propio resultado de
aplicar la clave privada al resumen, que es la firma electrónica propiamente dicha. La firma fechada añade a la firma básica información temporal sobre el momento de la firma o de su verificación y la firma validada añade a la firma fechada información sobre la vigencia del certificado empleado en el momento de la firma o de su verificación. Estas modalidades de firma están recogidas en las normas TS 101 733 y TS 101 903. La firma validada se denomina también firma completa (designada con las siglas ES-XL), porque incluye todos los elementos que permiten comprobar que el certificado utilizado por el firmante estaba vigente en el momento de la firma. Estas modalidades de firma se derivan respectivamente del formato PKCS#7 de RSA las basadas en el estándar TS 101 733 (CAdES) y del formato XMLDsig (o XAdES en una versión más avanzada) del consorcio W3C las basadas en el estándar TS 101 903. Además estas firmas se pueden codificar dentro de la especificación PDF 1.6 de Adobe, de forma que puedan ser verificadas con el software gratuito Acrobat Reader. La ventaja de utilizar el formato ES-XL por parte del firmante, es que se exonera al receptor del problema de
validar el certificado utilizado, porque en la firma ya se incluyen todos los elementos que garantizan su validez en el momento de la firma.
La utilización de firmas en XML es la elección evidente cuando el formato empleado para la formación de las propias facturas es también XML. Sin embargo, la firma XML puede aplicarse a cualquier tipo de documento, con independencia de su formato. Dentro de la firma electrónica en formato XML, existen diferentes “subtipos de formatos”, dentro de los cuales destacan por encima de todos el XML Dsig y la variante de este, el XML Advanced Electronic Signatures (XAdES). En toda firma XML, según el estándar XML DSig, existirían 3 modos de firma: • Enveloped, en el que la firma se añade al final del documento XML como un elemento más. Se firma todo lo inmediatamente anterior al documento. • Enveloping, en el que el documento se incluye dentro de la firma en la que se referencia lo firmado como objeto insertado en la firma. Ya que se referencian los objetos, este modelo permitiría distinguir lo que se firma, pudiendo firmar el objeto entero o
partes de él (asignando un id diferenciador). • Detached, en el que la firma y el documento se separan en dos archivos, la URL donde se encuentra el documento puede aparecer en la propia firma. XAdES, está basado en XML Dsig, pero con la ventaja de añadir diversas capas de seguridad a la firma y al XMLDSIG documento firmado. | <ds:Signature ID?>- - - - - - - - - + - - - - -+ En concreto, se pueden agregar los <ds:SignedInfo> | | <ds:CanonicalizationMethod/> | | datos relativos a la revocación y al <ds:SignatureMethod/> | | sello de tiempo, tal y como se (<ds:Reference URI? > | | (<ds:Transforms>)? | | muestra en el esquema:
| | | | | | | <ds:Object> | | <QualifyingProperties> | | <SignedProperties> | | <SignedSignatureProperties> | (SigningTime) | (SigningCertificate) | (SignaturePolicyIdentifier) | (SignatureProductionPlace)? | (SignerRole)? | </SignedSignatureProperties> | | <SignedDataObjectProperties> | (DataObjectFormat)* | (CommitmentTypeIndication)* | (AllDataObjectsTimeStamp)* | (IndividualDataObjectsTimeStamp)* | </SignedDataObjectProperties> | | </SignedProperties> | | <UnsignedProperties> | | <UnsignedSignatureProperties> | (CounterSignature)* | </UnsignedSignatureProperties> | | </UnsignedProperties> | | </QualifyingProperties> | | </ds:Object> | | </ds:Signature>- - - - - - - - - - - - - - - + | XADES <ds:DigestMethod> <ds:DigestValue> </ds:Reference>)+ </ds:SignedInfo> <ds:SignatureValue> (<ds:KeyInfo>)?- - - - - - - - | | | | | +
A pesar de que los datos relativos tanto al sellado de tiempo como a la revocación del certificado pueden ser de gran utilidad y aportar un gran valor añadido al proceso de firma, éstos no son obligatorios para dotar de validez a una factura electrónica. XAdES cuenta con el respaldo de W3C, OASIS y ETSI (European Telecommunications Standards Institute) y está especificado en el estándar TS 101 903 v.1.2.2. Referencia XAdES en la W3C http://www.w3.org/TR/XAdES/ Documento estandarización ETSI http://portal.etsi.org/esi/elsign.asp
¬ Esquema de agregación de datos relativos a la revocación y al sello de tiempo
Firmas PKCS#7/CMS
La firma CMS/PKCS7, esta compuesta por una serie de elementos que afectan a la firma, como son, el tipo de algoritmo hash (generalmente SHA1), el algoritmo de firma (generalmente RSA), el hash resultante del documento, el certificado digital al que se asocia la clave pública, la firma PKCS#1 en si misma, número de firmas (multifirma), ... Existen elementos opcionales y obligatorios, así como elementos firmados y no firmados. Se puede ampliar información del estándar en: http://www.ietf.org/rfc/rfc3369.txt La utilización tanto de PKCS7 como de CMS (Certificate Management Syntax, disponible en http://www.ietf.org/rfc/rfc2630.txt) permite dos variantes: Attached y
detached. En la modalidad “attachada” o embebida, tanto la firma en si como el documento del que trae causa se almacenan en un mismo fichero al estilo de un “zip”. En la versión “detachada” o disociada sólo se incluye la firma, por lo que es necesario disponer del documento original, en el momento de validar la firma. Al igual que ocurría en el entorno XML entre XMLDSig y XAdES, existe un derivado del CMS, denominado CAdES (CMS Advanced Signature) que incorpora junto a la firma electrónica los tokens (indicadores) de tiempo y validación. En la práctica, CAdES es poco utilizado, en parte por la tendencia de uso de XML y en parte por la falta de herramientas de desarrollo que permitan su
¬ Utilidad de firma de documentos en formato PKCS#7/CMS
aplicación. No obstante, debe ser tenida en cuenta. Más información de CAdES en: http://www.ietf.org/internetdrafts/draft-ietf-smime-cades-00.txt
tradicionales utilizan el formato EDIFACT para codificar los mensajes, y redes de valor añadido (VAN: Value Added Network) para transmitirlos y distribuirlos. Este formato está recogido en el estándar ISO 9735 Electronic Data Interchange for administration, commerce and transport (EDIFACT). En un sentido más amplio, son sistemas de intercambio de datos los que permiten que el destinatario de la transmisión pueda utilizar un medio de recepción informatizado que le evite el proceso de reintroducir los datos de tales mensajes en los programas informáticos que los tratan, como sucedería por ejemplo, en el caso de las
El EDI implica la transferencia electrónica de ordenador a ordenador de datos comerciales o administrativos que se estructuran en un mensaje normalizado que permite su procesado automático. En sentido estricto, los sistemas EDI
INTERCHANGE FUNCTION GROUP (optional) MESSAGE (or only) MESSAGES LNZ ' UNE ' UNT ' COMPOSITE DATA ELEMENT : '
UNA UNB
UNH data segment
¬ Estructura de intercambio en EDI
COMPONENT DATA ELEMENT
facturas transmitidas en papel o en formatos no directamente interpretables por el ordenador de destino. En la actualidad los sistemas EDI legalmente válidos (según el Art.18.1.b del RD 1496/2003) garantizan la autenticidad e integridad del mensaje, de dos formas: • Mediante una firma electrónica avanzada de acuerdo con lo dispuesto en el artículo 2.2 de la Directiva 1999/93/CE del Parlamento Europeo y del Consejo, de 13 de diciembre de 1999, por la que se establece un marco comunitario para la firma electrónica, basada en un certificado reconocido y creada mediante un dispositivo seguro de creación de firmas, de acuerdo con lo dispuesto en los apartados 6 y 10 del artículo 2 de la mencionada Directiva. • Mediante un intercambio electrónico de datos (EDI), tal como se define en el artículo 2 de la Recomendación 1994/820/CE de la Comisión, de 19 de octubre de 1994, relativa a los aspectos jurídicos del intercambio electrónico de datos, cuando el acuerdo relativo a este intercambio prevea la utilización de procedimientos que garanticen la autenticidad del origen y la integridad de los datos. Cuando se emplea la firma electrónica
en EDI, se utilizan las posibilidades del estándar a través de dos variantes: • Cabeceras y pies de seguridad (USH “security header” - UST “security trailer”), que permiten firmar cada mensaje del intercambio. • Mensaje AUTACK que permite firmar todos los mensajes de un intercambio. Aunque cuando se utiliza EDI en el intercambio electrónico de facturas no es necesario el uso de la firma electrónica, éste está previsto y en España se está adoptando de forma generalizada. Puede obtenerse más información sobre EDIFACT en: http://www.gefeg.com/jswg/ http://www.unece.org/cefact/ http://www.aecoc.es
Firma en documentos PDF
Adobe ha definido dentro de la especificación PDF un formato de firma propietario apoyado en la generación de firmas en formato PKCS#7 y su inserción en un documento PDF. Este tipo de firmas está teniendo un éxito importante, principalmente, por la posibilidad de que cualquiera pueda validar las firmas con un producto de distribución masiva: el Adobe Reader. Las principales ventajas de las firmas en PDF son la sencillez de uso al alcance de cualquier persona y la generalización de su validador.
Existen soluciones de firma de ficheros PDF muy interesantes tanto de Adobe como de terceros. Los productos de Adobe permiten llevar a cabo de forma muy sencilla la firma electrónica, por ejemplo con el programa Adobe Acrobat. Algunos productos de servidor de Adobe permiten extender las funciones del Reader, habilitando, por ejemplo, la firma electrónica, lo que no es posible con el uso básico del Reader por sí solo. También hay soluciones de terceros
para firmar archivos PDF por lotes desde aplicaciones Java o soluciones individuales que no requieren la instalación de productos de Adobe. El formato PDF tiene interés, además, por otros motivos: permite programar en su interior funciones (semejantes a las que permite javascript) que facilitan la introducción y validación de datos en formularios y permite codificar estos datos en XML para facilitar su exportación a diferentes sistemas on-line.
¬ Detalle de firma en factura PDF
Anexo I. Introducción a la firma electrónica y certificación electrónica
PSC y CA
En las siguientes páginas se utilizan dos términos que frecuentemente se usan como sinónimos pero que no lo son. Prestador de Servicios de Certificación (PSC) es un término legal, que se define en la Directiva 93/99 y en la ley 59/2003, mientras que Autoridad de Certificación (AC) es un concepto técnico expresamente recogido en la recomendación X.509 de la UIT-T. El término PSC es más amplio puesto que incluye a las AC que “expiden certificados electrónicos” y también a aquellos que “prestan otros servicios en relación con la firma electrónica”, por ejemplo AV (Autoridad de Validación), AR (Autoridad de Registro), AST (Autoridad de Sellado Temporal). Con frecuencia se usan sus términos equivalentes en inglés: CSP, CA, VA, RA y TSA.
La firma manuscrita permite certificar el reconocimiento o conformidad sobre un documento por parte del firmante, de forma que tiene una gran importancia desde el punto de vista legal. Aunque existen diferentes formas de mostrar o demostrar conformidad con diferentes actuaciones, o de cerrar acuerdos entre personas o empresas, la firma manuscrita, tiene un reconocimiento particularmente alto. La firma manuscrita tiene las siguientes propiedades: • Sólo puede ser realizada por una persona • La puede comprobar cualquier persona, con la referencia de una muestra El problema del reconocimiento de
firma se resuelve, cuando ésta es manuscrita, mediante la comparación con una muestra (la del carné de identidad, la de la tarjeta de crédito). Algo que es tan fácil de hacer y comprobar en el mundo real, no es tan sencillo en el mundo virtual. Requiere el uso de la Criptografía y el empleo de propiedades matemáticas de los mensajes codificados.
de determinados problemas complejos) que, siendo públicos (es decir, supuestamente conocidos por un criptoanalista atacante) permitan garantizar la inviolabilidad de los mensajes protegidos por ellos, al menos durante el tiempo en que pueda ser útil el conocimiento de la información protegida. Asimismo, no debe ser posible obtener las claves a partir del conocimiento de fragmentos cifrados y en claro del mensaje.
Criptografía Cifrado Simétrico
El objetivo básico de la criptografía es encontrar sistemas que permitan hacer llegar determinada información considerada secreta, desde un lugar origen a otro destino, de forma tan segura que, si el mensaje es interceptado, un atacante no pueda reconocer el mensaje. Uno de los objetivos de la criptografía moderna es encontrar algoritmos basados en principios matemáticos (como la imposibilidad de tratamiento computacional La característica principal de la criptografía simétrica es que, utilizando el mismo algoritmo y la misma clave, permite obtener el texto cifrado a partir del texto en claro y viceversa. Por este motivo, puesto que el algoritmo es público, es necesario mantener el secreto de la clave entre las partes que intervienen. El cifrado simétrico es el más fácil de entender, porque se parece a la forma en que
¬ Compartición de claves simétricas
La clave que permite intercambiar información entre Alicia y Borja debe de ser diferente de la que comparte Alicia y Carlos.
Combinaciones de 6 usuarios tomados de 2 en 2
Para 1.000 usuarios, 499.500 cajas
6! 2! x 4!
=15 cajas
¬ Problema de multiplicidad de intervinientes y llaves
No es practicable un sistema en el que haya que gestionar claves para cada dos personas
guardamos las cosas en la vida real. Veamos un ejemplo: Supongamos que tenemos una caja con una cerradura. Si hacemos una sola copia de la llave y se la damos a nuestro interlocutor, disponemos de un mecanismo para intercambiar objetos o mensajes de forma confidencial y segura con él. De esta forma se puede comprobar que el envío lo hemos hecho nosotros porque somos los únicos que hemos podido introducir el documento (el uso de la caja actúa como firma) y además sabemos que nadie más puede conocer su contenido mientras viaja (uso como sobre seguro). El mayor problema aparece cuando deseamos que un conjunto numeroso de interlocutores puedan mantener comunicaciones entre ellos. En este caso son necesarias muchas cajas y el doble de llaves. No pueden tenerse cajas y llaves iguales para interlocutores distintos, ya que ello
conllevaría el riesgo de suplantación o de pérdida del secreto en el mensaje.
Existe la posibilidad de encontrar algún sistema que utilice claves distintas para cifrar y descifrar un mensaje, de forma que el conocimiento de la clave de cifrado no permita el descifrado del mensaje e, inversamente, que el conocimiento del texto cifrado y de la clave de descifrado no diga nada acerca de la clave de cifrado. Este concepto propuesto por Hellman y Diffie en 1976 tiene uno de los exponentes más difundidos en el algoritmo de Rivest, Shamir y Adleman (RSA), basado en la intratabilidad computacional de la factorización en los números primos que los componen, de grandes números compuestos. En los algoritmos con parejas de claves, llamados también asimétricos o de clave pública, una de las claves se mantiene secreta, mientras que la otra se hace libremente disponible: pública.
El cifrado asimétrico es difícil de entender, y, a veces, incluso difícil de creer. Para intentar explicarlo, sin recurrir a las matemáticas, recurriremos de nuevo a un símil de cajas y de llaves. En este caso, no utilizamos cajas normales, sino “cajas de mago”. Supongamos que tengo una caja de doble fondo, cuyo anterior propietario era un mago, con una tapa que se abre de dos formas distintas con diferentes llaves. La propiedad de la caja es que lo que se introduce cuando se abre con una llave pasa a un compartimento al que solo se puede acceder si se utiliza la otra llave. En esto, ambas llaves son equivalentes, es decir, lo que se introduce usando una llave sólo puede recuperarse utilizando la otra. Si una de las llaves la guardo de la forma más segura de que soy capaz, y de la otra hago copias que reparto ampliamente o que difundo a través de un medio público,
cualquiera que tenga una de esas llaves podrá entregarme sólo a mi un objeto sin que los demás lo conozcan. Sólo yo seré capaz de recoger el envío. En ese caso, la caja se utiliza como sobre seguro. Por otro lado, si decido demostrar que sólo yo he tenido acceso a determinado dato u objeto, puedo introducirlo con mi llave en la caja. Cualquiera que abra la caja y encuentre el objeto, sabe que sólo yo lo he podido introducir allí. En este caso, la caja es la herramienta que me permite realizar mi firma electrónica. Si cada persona dispone de una caja como la mía y reparte las llaves públicas a las demás, todos disponemos de un sistema para enviarnos mensajes de forma segura o para firmar envíos. En el caso de 1.000 personas, necesitamos 1.000 cajas y cada uno tenemos nuestra clave privada y las claves públicas de las otras 999. Para poder comparar, hay que pensar que
¬ Caja de mago: una sola llave de entrada y muchas copias de la llave de salida
La llave de entrada es la PRIVADA, y la de salida, con múltiples copias es la PÚBLICA.
¬ Analogía de múltiples cajas y claves
Ya no es necesario compartir llaves por Cada usuario tiene su caja, tiene su llave privada y la pública de todos los demás cada dos usuarios, como con el sistema de clave simétrica, sino que cada usuario tiene su pareja de claves Pública-Privada.
Para 1.000 usuarios, 1.000 cajas
con el sistema de cifrado simétrico, con cajas convencionales, serían necesarias 499.500 cajas y el doble de llaves (Combinaciones de 1.000 elementos tomados de dos en dos). Con principios equivalentes, la firma electrónica se basa en los sistemas criptográficos de clave pública. En estos sistemas se tiene un algoritmo que toma un texto en claro y lo cifra con una clave. El texto cifrado se restituye al texto original mediante otra clave distinta y vinculada a la de cifrado. Si la clave de cifrado sólo la tiene una persona y la de descifrado la conoce todo el mundo, lo que cifre esa persona podrá ser utilizado como su firma electrónica, ya que sólo ella la puede realizar y en cambio todo el mundo la puede reconocer. Dando un paso más: si tomamos un documento electrónico y le aplicamos un algoritmo tal que nos permita obtener un código corto que dependa del contenido del documento (algo así como la esencia del documento, su huella dactilar, tal que si cambia cualquier carácter del documento,
cambia el resultado) y ciframos el código corto con la clave privada, entonces obtenemos una firma electrónica que permite comprobar si se han realizado modificaciones sobre el documento.
Frecuentemente, a este código se le denomina MAC (Message Authentication Code), y se calcula en el momento de la firma, y también cuando se desea realizar el reconocimiento. El resultado del algoritmo y el de descifrado de la firma electrónica deben coincidir: es el código corto que permite comprobar que nadie ha modificado el documento que se utilizó como base cuando se llevó a cabo la firma electrónica.
Aparentemente, ha quedado resuelto el problema de realizar y comprobar la firma electrónica, pero todavía es necesario un elemento fundamental: el Prestador de Servicios de Certificación. Para ver su necesidad, podemos plantearnos el caso en el que dos personajes, Alicia y Roberto, se intercambian sus claves públicas mediante un sistema de comunicaciones. Es posible que se produzca la intercepción de los mensajes y que tanto Alicia como Roberto queden confundidos acerca de sus
por parte de un interlocutor ilegítimo que se inserta en el circuito de intercambio de claves, se cuenta con una entidad reconocida por parte de los participantes denominada Prestador de Servicios de Certificación.
¬ Función de las autoridades de Certificación
Ya no es posible el ataque de “hombre en el medio” porque no puede tener acceso a la clave privada de la Autoridad de Certificación, y por tanto, no puede falsificar los certificados.
¬ Problema “Man in the middle”
Hay que resolver este problema aunque sea más teórico que real.
identidades y claves. Una vez intercambiadas las claves a través de este atacante, sería posible para él descodificar y recodificar los mensajes sin que Alicia ni Roberto se percataran de que todos sus mensajes son conocidos y suplantados por el atacante.
Para evitar la interceptación de los mensajes
El Prestador de Servicios de Certificación recibe la petición de un participante para que emita un certificado que garantice que su clave pública es precisamente la suya, para lo cual realiza las indagaciones necesarias que permitan confirmar la identidad del peticionario. Cuando tiene certeza de esta identidad emite un certificado en el que se recogen los datos de identificación e inseparablemente la clave pública del peticionario. En el certificado, todos estos datos van cifrados con la clave privada del Prestador de Servicios de Certificación. Dado que la clave pública del Prestador de Servicios de Certificación es conocida por todos los interlocutores, cualquiera es capaz
de extraer los datos del certificado. Sin embargo, nadie es capaz de suplantar al Prestador de Servicios de Certificación emitiendo certificados falsos, ya que carece de su clave privada.
mensajes confidenciales. Cuando un participante comunica a otro su certificado, indica el Prestador de Servicios de Certificación utilizada. La llave pública del Prestador de Servicios de Certificación debe ser conocida por todos y es la única que necesita ser conocida previamente. Habitualmente está incorporada al software de realización y verificación de firmas electrónicas, o es posible obtenerla a partir de sistemas de difusión públicos, tales como servidores Web. Por lo dicho hasta ahora, vemos que el Prestador de Servicios de Certificación debe ser una Entidad de Confianza (Trusted Third Party), Conocida ampliamente, cuya Política de Certificación incluya cláusulas aceptables por los diferentes interlocutores, que permita, entre otras cosas, la Verificación de identidad, que dé información sobre Uso y validez de los certificados y que realice Gestión de certificados revocados (para impedir que claves privadas expuestas puedan tener vigencia) y ofrezca la Lista de certificados expedidos. Dado que en una red existe más de un Prestador de Servicios de Certificación, la selección de las autoridades de certificación adecuadas para cada uso vendrá dada por las características de su Política de Certificación, o por el reconocimiento de alguna de ellas por parte de entidades que aceptan sus certificados. Se han desarrollado sistemas jerárquicos que permiten que las aplicaciones confíen en los certificados de nivel inferior en función de la confianza que otorgan al certificado de la autoridad raíz.
Una vez que Alicia y Roberto cuenten con sus respectivos certificados, ya no intercambiarán las claves a través del medio de transmisión, sino que intercambiarán sus certificados. Volviendo al símil de las cajas, el Prestador de Servicios de Certificación comunica su clave pública a través de los periódicos y proporciona pruebas de que es una entidad de confianza por lo que sus certificados pueden ser considerados válidos. Utiliza su caja, cifrada con su llave privada para proporcionar la información sobre la identidad que se certifica. Entre la información proporcionada está la clave pública asociada a la identidad del certificado. A partir del certificado, es posible, por tanto, obtener la clave pública de nuestro interlocutor y, a partir de allí reconocer su firma o tener la posibilidad de enviarle
Los parámetros que definen a un Prestador de Servicios de Certificación son su dirección de red (nombre distinguido) y su clave pública. Además es necesario especificar en su identificación: Entidad Emisora del Certificado, Departamento u Organización responsable de la custodia de la clave privada y Ubicación (Ciudad, Pais). También son valorables aspectos como Identificativo Fiscal o Referencia Registral.
Ya existen algunos casos concretos, como el que permite la transmisión y negociación de acciones mediante el Sistema de Anotaciones en Cuenta, que se utiliza en el Mercado de Valores. Algunas de estas entidades tienen actividades independientes y adicionales a las de las autoridades de certificación, que se centran en la Autenticación de los Intervinientes y las funciones derivadas.
Entidad de Registro El esquema completo
Puesto que al realizar la comprobación de la identidad del usuario en la primera certificación es necesario realizar unas actividades especiales, el Prestador de Servicios de Certificación lleva asociada una Entidad de Registro. Esta Entidad de Registro mantiene información sobre los aspectos relevantes del registro y sobre los procedimientos de identificación utilizados, así como la vinculación del registro con la identidad que garantiza un Prestador de Servicios de Certificación. Además de este tipo de Entidades de Registro, existen otras, que demuestran la realización en el tiempo de determinados Actos Electrónicos: Certificaciones en presencia de un fedatario (como en el caso de contratos firmados ante notario), Certificaciones de Acreditación respecto a la capacidad suficiente para obrar o para representar a terceros, Registro de contratos o transmisiones patrimoniales. Con todos los elementos descritos, ya es posible tener una idea sobre la forma en que se realizan los diferentes procesos de firma, verificación,... REALIZACIÓN DE LA FIRMA Partimos del documento original al que se le calcula el HASH (o MAC), función resumen unidireccional, que lo identifica unívocamente. El resultado de aplicar esta función se cifra con la clave privada del titular del certificado (siguiendo con el símil, se introduce en la “caja de mago”). Lo que se envía al destinatario es el conjunto formado por el documento, el hash (o MAC) firmado y el certificado. COMPROBACIÓN DE LA FIRMA El receptor recibe el conjunto formado por el documento, el hash firmado y el certificado. A partir del certificado, podemos extraer la clave pública del remitente. Con dicha clave pública podemos abrir la “caja de mago” y por tanto obtener el hash que se calculó en origen. Dado que disponemos del documento,
¬ Símil de firma electrónica
Se aplica la función resumen sobre el documento (que obtiene algo semejante a la huella dactilar del documento) y se cifra con la llave privada del firmante. Se envía el documento, el certificado y el resultado de la operación anterior, que es la firma electrónica. La firma electrónica es diferente para cada documento firmado por un mismo usuario y para el mismo documento si lo firman distintos usuarios.
podemos calcular su hash por nuestra cuenta. Al comparar los dos “hash”, el que se calculó en origen y el que se calculó en destino, ambos deben coincidir. En caso de que no coincidan, esto quiere decir que o bien el documento o bien el “hash firmado” han tenido alguna incidencia en la transmisión que afecta a su contenido, y por tanto, la firma no es válida.
cumplir las siguientes funciones de seguridad: 1 Integridad, 2Identificación del Firmante, 3Prueba de Conformidad con lo firmado, 4Momento de la Firma Además existen otros principios de seguridad que igualmente se satisfacen, según las características del certificado y del protocolo empleado, como disponibilidad, auditabilidad, fiabilidad, confidencialidad, detección de mensajes faltantes en una secuencia, acuse
Un sistema de Firma Electrónica permite
¬ Verificación de firma electrónica
Del certificado se obtiene la clave pública del firmante con lo que se puede descifrar la firma para obtener el resultado de la función resumen aplicada por el firmante. Además, aplicando el mismo algoritmo sobre el documento se calcula de nuevo la función resumen. Ambos valores, el original y el obtenido en destino deben ser iguales.
de recibo, poder bastante para el acto y evidencia legal. Integridad No es posible que el contenido del mensaje sufra ninguna modificación accidental o intencionada, una vez firmado. Identificación del firmante Es posible saber quién es el emisor del mensaje y sus atributos principales.. Prueba de Conformidad con lo firmado El firmante está de acuerdo con el contenido del documento o se vincula con él de alguna forma (como autor, como revisor, dándose por enterado, etc.) Momento de la Firma Si la firma se lleva a cabo de forma correcta, incorporando información temporal fehaciente, es posible saber que el documento existía antes de un momento dado, que es el que se indica como momento de la firma.
Custodia de claves y dispositivos seguros de creación de firma
Un aspecto importante en un entorno de facturación electrónica que emplee certificados digitales es el referido a la custodia de la clave privada asociada a la clave pública y al certificado empleado para la firma de facturas. Lo que comúnmente conocemos como certificado digital, consta en realidad de tres elementos importantes:
• La clave privada: se trata de una clave generada de forma aleatoria a partir de unos algoritmos matemáticos de una determinada longitud. En la actualidad se suele emplear para claves personales el algoritmo RSA y claves de 1.024 bits. Esta clave debe ser conocida y manejada únicamente por el usuario de esta. • La clave pública: esta clave esta generada en base a la anterior, si bien resulta extremadamente complejo inferir la clave privada una vez conocida esta clave pública. El objetiva de esta clave es permitir su intercambio, por lo cual su naturaleza es pública. • La clave pública generada se incorpora, junto con los datos del usuario del certificado (nombre, DNI, empresa, …) a un documento formado en base al estándar X509 v.3. Este documento es firmado por una Autoridad de Certificación, que de esta manera certifica la autenticidad de todos los datos contenidos en él. Este documento firmado por la Autoridad de Certificación es el certificado digital propiamente dicho. La seguridad del sistema de firmas radica por tanto en la protección de la clave privada. Esta clave puede ser almacenada de diferentes formas: • Almacén en claro: La clave privada se almacena en el disco sin ninguna protección, salvo, en su caso, la protección habitual para ficheros sensibles.
• Almacén en repositorios especiales: Microsoft, dispone de un gestor de claves y certificados propio, el cual te permite proteger la clave privada con una contraseña. El principal problema radica en la dependencia a una plataforma y la escasa seguridad del proceso. • Almacén PKCS12 / PEM: se trata de archivos contenedores de la clave privada, la clave pública y el certificado. La clave privada puede ser protegida por contraseña. • Almacén en Tarjetas de memoria: algunas tarjetas chip de memoria permiten el almacén y recuperación de claves y certificados. Su principal ventaja es su portabilidad y su desventaja es que las operaciones criptograficas se realizan fuera de la tarjeta. • Almacén en tokens criptográficos: las tarjetas criptográficas dotan de la misma portabilidad que la tarjeta de memoria con el añadido de que las operaciones criptográficas se realizan en la propia tarjeta, por lo que la clave privada nunca sale de la misma.
• Almacén en HSM: el hardware criptográfico otorga la misma funcionalidad que los tokens pero están optimizados para realizar procesos en batch. Es recomendable su uso cuando se realicen muchas operaciones criptográficas y se quiera dotar al sistema de una gran seguridad. Además puede acompañarse de aceleradores criptográficos que optimicen su funcionalidad. Para la utilización de las claves de firma se recomienda en términos absolutos el uso de algún Hardware Criptográfico HSM, por su mayor eficiencia (en términos de velocidad y seguridad) frente a la alternativa de almacenamiento software. No obstante dependerá del alcance del proyecto la decisión respecto al medio a emplear, si bien debemos tener en cuenta que la ley de firma electrónica exige la utilización de dispositivos seguros de creación de firma para la generación de “firmas reconocidas”.
¬ El DNI electrónico es considerado un dispositivo seguro de creación de firma
Validez legal de la factura electrónica
La factura electrónica es plenamente legal en toda Europa. Las normas aplicables son fundamentalmente las siguientes: • Sexta Directiva del Consejo, de 17 de mayo de 1977, en materia de armonización de las legislaciones de los Estados miembros relativa a los impuestos sobre el volumen de negocios. Sistema común del IVA: Base imponible uniforme (77/388/CEE). • Directiva 1999/93/CE del Parlamento Europeo y del Consejo, de 13 de diciembre de 1999, por la que se establece un marco comunitario para la firma electrónica.
• Directiva 2006/112/CE del Consejo, de 28 de noviembre de 2006, relativa al sistema común del impuesto sobre el valor añadido. • Directiva 2001/115/CE del Consejo, de 20 de diciembre de 2001, por la que se modifica la Directiva 77/388/CEE con objeto de simplificar, modernizar y armonizar las condiciones impuestas a la facturación en relación con el Impuesto sobre el Valor Añadido. • Ley Orgánica 15/1999, de 13 de diciembre, de Protección de Datos de Carácter Personal • Ley 37/1992, de 28 de diciembre, del Impuesto sobre el Valor Añadido. • Ley 58/2003, de 17 de diciembre, General Tributaria. • Ley 59/2003, de 19 de diciembre, de Firma Electrónica. • Ley 53/2002, de 30 de diciembre, de Medidas Fiscales, Administrativas y del Orden Social (artículo 164), • Ley 1/2000, de 7 de enero, de Enjuiciamiento Civil. • LEY 11/2007, de 22 de junio, de acceso electrónico de los ciudadanos a los Servicios Públicos • Ley 30/2007, de 30 de octubre, de Contratos del Sector Público. • LEY 56/2007, de 28 de diciembre, de Medidas de Impulso de la Sociedad de la Información. • Real Decreto 1496/2003, de 28 de noviembre, por el que se aprueba el Reglamento por el que se regulan las obligaciones de facturación, y se modifica el Reglamento del Impuesto sobre el Valor Añadido.
• Real Decreto 87/2005, de 31 de enero, por el que se modifican el Reglamento del Impuesto sobre el Valor Añadido, aprobado por Real Decreto 1624/1992, de 29 de diciembre, el Reglamento de los Impuestos Especiales, aprobado por Real Decreto 1165/1995, de 7 de julio, y el Reglamento por el que se regulan las obligaciones de facturación, aprobado por Real Decreto 1496/2003, de 28 de noviembre. • Orden HAC/1181/2003, de 12 de mayo, por la que se establecen normas específicas sobre el uso de la firma electrónica en las relaciones tributarias por medios electrónicos, informáticos y telemáticos con la Agencia Estatal de Administración Tributaria. • Resolución, de 24 de julio de 2003, de la Dirección General de la Agencia Estatal de Administración Tributaria por la que se establece el procedimiento a seguir para la admisión de certificados de entidades prestadoras de servicios de certificación electrónica. • ORDEN EHA/962/2007, de 10 de abril, por la que se desarrollan determinadas disposiciones sobre facturación telemática y conservación electrónica de facturas, contenidas en el Real Decreto 1496/2003, de 28 de noviembre, por el que se aprueba el reglamento por el que se regulan las obligaciones de facturación. • ORDEN PRE/2971/2007, de 5 de octubre, sobre la expedición de facturas por medios electrónicos cuando el destinatario de las mismas
sea la Administración General del Estado u organismos públicos vinculados o dependientes de aquélla y sobre la presentación ante la Administración General del Estado o sus organismos públicos vinculados o dependientes de facturas expedidas entre particulares. (BOE n. 247 de 15/10/2007). • RESOLUCIÓN de 24 de octubre de 2007, de la Agencia Estatal de Administración Tributaria, sobre procedimiento para la homologación de software de digitalización contemplado en la Orden EHA/962/2007, de 10 de abril de 2007. Históricamente, la evolución normativa ha sido la siguiente: A partir de la Ley 10/1985, de 26 de abril, de modificación parcial de la Ley General Tributaria, se instaura la obligación de expedir factura en las operaciones que realicen los empresarios o profesionales determinados por la ley. Posteriormente, la Ley 37/1992, de 28 de diciembre, del Impuesto sobre el Valor Añadido2 reconoce la validez de la facturación telemática, aunque sin entrar en detalles respecto a su formulación. Hasta la publicación del Real Decreto 1496/2003, de 28 de noviembre, la facturación ha sido regulada por la disposición dictada en desarrollo de la norma
legal indicada, el Real Decreto 2402/1985, de 18 de diciembre3, ya derogado. El artículo 9 bis del Real Decreto 2402/1985, de 18 de diciembre, reconocía expresamente la misma validez a las facturas emitidas por medios electrónicos que a las originales: “(…) las facturas transmitidas por vía telemática a que se refiere el artículo 88.2 de la Ley del Impuesto del Valor Añadido, tendrán la misma validez que las facturas originales. (…)”. Igualmente, el legislador contemplaba el empleo de la factura electrónica en el citado artículo para imponer a empresarios y profesionales la obligación de solicitud a la Agencia Estatal de Administración Tributaria el empleo de estos distintos medios para que, una vez examinada la solución propuesta, resuelva la Agencia en el plazo de seis (6) meses sobre su oportunidad. Este artículo remitía al Ministerio de Economía y Hacienda para que dictara la correspondiente norma de aplicación. Esta Orden de 22 de marzo de 1996, fue modificada y derogada a su vez por la Orden HAC/3134/2002, de 5 de diciembre, sobre un nuevo desarrollo del régimen de facturación telemática previsto en el artículo 88 de la Ley 37/1992, de 28 de diciembre, del Impuesto sobre el Valor Añadido, y en el artículo 9 bis del Real Decreto 2402/1985, de 18 de diciembre, que también está derogada en la actualidad.
2 Art. 88 Ley 37/1992, de 28 de diciembre, del Impuesto Sobre el Valor Añadido 3 Art. 9 bis) Real Decreto 2402/1985, de 18 de diciembre
En aras de aminorar la presión fiscal indirecta del contribuyente, así como de facilitar todo aquello que redunde en beneficio de la economía nacional sin menoscabo de la gestión y control tributario, y en cumplimiento de lo dispuesto en el mencionado articulo 9 bis del Real Decreto 2402/1985, la Orden HAC/3134/2002, de 5 de diciembre, sobre un nuevo desarrollo del régimen de facturación telemática previsto en el artículo 88 de la Ley 37/1992, de 28 de diciembre, del Impuesto sobre el Valor Añadido, y en el artículo 9 bis del Real Decreto 2402/1985, de 18 de diciembre, desarrolla el régimen jurídico aplicable a los sistemas de facturación por medios telemáticos, definiendo el marco jurídico de las obligaciones formales y materiales de todos los sujetos que intervienen en el mismo, sustituyendo las facturas en soporte papel por facturas electrónicas que deberán conservarse en soportes magnéticos u ópticos de acuerdo con las especificaciones contenidas en la presente Orden. Los principios que informan los sistemas de facturación telemática son: • El interés general que supone la aprobación de un sistema de facturación por vía telemática. • Eficacia de la gestión empresarial y de la actividad fiscalizadora de la Administración. • Principio de integridad de los datos, debiendo conservarse íntegramente en los ficheros la información contenida en las facturas. • Validez justificativa de las facturas. • El respeto al artículo 31 de la
Constitución Española implica el principio de efectividad total en materia de tributos. Por la Orden EHA/962/2007 se desarrollan y aclaran determinados aspectos relacionados con la remisión y conservación de facturas y documentos sustitutivos en el marco del Real Decreto 1496/2003, de 28 de noviembre, por el que se aprueba el Reglamento por el que se regulan las obligaciones de facturación. También añade por primera vez la posibilidad de la digitalización certificada de facturas papel para convertirlas en e-facturas legales. Así mismo esta Orden deroga la Orden HAC/3134/2002, de 5 de diciembre, sobre un nuevo desarrollo del régimen de facturación telemática previsto en el artículo 88 de la Ley 37/1992, de 28 de diciembre, del Impuesto sobre el Valor Añadido, y en el artículo 9 bis del Real Decreto 2402/1985, de 18 de diciembre. Respecto a la normativa comunitaria existente, hasta finales del 2001 la regulación de la factura electrónica era bastante limitada, ciñéndose exclusivamente a señalar los requisitos mínimos que los Estados Miembros habían de exigir en las facturas. Con la aprobación de la Directiva 2001/115/CE del Consejo, de 20 de diciembre de 2001, se armoniza el espacio comunitario y se introducen novedosas cuestiones relativas a la facturación. Entre estas novedades podemos señalar la enumeración de los supuestos de obligatoriedad de expedición, las menciones
obligatorias que habrá de contener toda factura, la obligación de utilización de nuevas tecnologías, etc. Un aspecto interesante, es que algunas de las cuestiones abordadas por la Administración en el Real Decreto 1496/2003, como por ejemplo el tratamiento de las facturas rectificativas, no son de carácter novedoso, aunque en el tiempo transcurrido no se habían adoptado como prácticas empresariales. Este hecho junto con la actualización normativa en la materia, hacían necesaria la aprobación de norma que recogiera, la dispersa y no actualizada, legislación existente. De hecho se señala expresamente que las referencias hechas en los distintos textos normativos al Real Decreto 2402/1985, de 18 de diciembre, se entenderán realizadas al Real Decreto 1496/2003, de 28 de diciembre, por el que se regula el Reglamento de las obligaciones de facturación. Las empresas españolas tienen la obligación legal de expedir y entregar factura o documentos sustitutivos, en los casos permitidos por la ley, en relación con todas las operaciones comerciales que realicen en el desarrollo de su actividad. Este deber legal va acompañado, en su caso, de la obligación de cumplimiento de la normativa vigente aplicable a la factura electrónica, la cual señala como requisitos obligatorios mínimos, que han de contener tanto las facturas que se emitan como sus copias, los siguientes datos4: • Número de la factura y, en su caso, serie. El uso de series diferentes añade una gran flexibilidad a las diferentes
4 Art. 6 y 7 RD 1496/2003
modalidades de facturación, entre las que se podrían identificar la “autofacturación” y la “facturación por terceros”. • Fecha de expedición. En algunos casos esta fecha coincidirá con la de entrega del bien o de prestación de servicio, pero cuando no coincida, no puede superar el plazo previsto por la normativa. • Nombre y apellidos, o razón social, tanto del obligado a expedir la factura como del destinatario de la misma. La factura habrá de consignar la denominación social de la forma que esté registrada, es decir, para su validez, la factura deberá contener el nombre completo registrado en la escritura de constitución inscrita en el Registro Mercantil, no revistiendo validez los nombres comerciales ni las posibles abreviaturas, salvo las que debido a limitaciones técnicas no permitan hacer constar el nombre completo y sean de común uso aceptadas (tales como S.A., S.L., SC, etc.) • Número de Identificación Fiscal. En consideración a la Directiva 2001/115/CE las empresas antepondrán las letras ES al CIF otorgado por la Administración Tributaria (en base al estándar internacional ISO-3166 alfa2, que sirve para identificar al Estado miembro que haya atribuido el Número de identificación fiscal). • Domicilio físico de los obligados tributarios, tanto emisor como
destinatario. No tiene por qué coincidir con el lugar en el que se hace la entrega de bienes y servicios. Este dato puede figurar en la factura, pero no es un requisito esencial para su validez. • Descripción de operaciones. Señalando, de forma destacada, la fecha de entrega del bien o de la prestación del servicio. En el supuesto, que para dar cumplimiento a este requisito se haga uso de la información contenida en albaranes, este hecho habrá de ser mencionado en la respectiva factura, haciendo referencia de manera inequívoca al correspondiente albarán, el cuál deberá conservarse debidamente anexado a la factura. Esto es así, debido a la calificación del albarán como soporte documental de las operaciones realizadas, es decir, tendrá la consideración de parte integrante de la factura a la que se adjunte y estará sometido a las mismas obligaciones de conservación que la referida factura. Si el destinatario de la factura fuera empresario o profesional, podrán agruparse en una sola factura todas las operaciones llevadas a cabo en distintas fechas de un mes natural. Igualmente, podrá realizarse la agrupación señalada en una única factura las distintas operaciones realizadas con el mismo proveedor cuando el obligado a la expedición sea el sujeto pasivo del impuesto (IVA). • Tipo o tipos impositivos aplicables a
las operaciones. O mención expresa de la causa de exención o no sujeción, en su caso. • La cuota repercutida.
Una norma que afecta a la implementación de la Factura Electrónica es la Ley 59/2003 de Firma Electrónica en la que se recoge la equiparación de la firma electrónica reconocida a la manuscrita y establece que no puede negarse el reconocimiento legal de cualquier firma electrónica, incluso de las modalidades simple o avanzada, por el hecho de presentarse en formato electrónico. Esta Ley constituye la transposición de la Directiva 1999/93. Las variantes técnicas de realización de firma electrónica son muy amplias. En la Directiva 2001/115 que regula la factura electrónica a nivel europeo, se exige al menos el empleo de firma electrónica avanzada, aunque en España el legislador ha optado por requerir el nivel más exigente definido en la Directiva: el de firma electrónica reconocida (qualified electronic signature en inglés). En la realización de la factura electrónica, la forma más sencilla de dotar de validez jurídica al documento electrónico que la contiene, consiste en incorporarle una firma electrónica. El artículo 18 del Real Decreto-1496/2003 establece expresamente que será válida una firma electrónica avanzada de acuerdo con lo dispuesto en el artículo 2.2 de la Directiva 1999/93/CE del Parlamento Europeo y del Consejo, de 13 de diciembre de 1999, por la que se establece un marco comunitario para la
firma electrónica, basada en un certificado reconocido y creada mediante un dispositivo seguro de creación de firmas, de acuerdo con lo dispuesto en los apartados 6 y 10 del artículo 2 de la mencionada Directiva. Es decir, cualquier certificado reconocido (o cualificado si se utiliza la traducción directa de la Directiva) es válido. La propia cualidad del certificado se establece en normas técnicas y económicas que emanan de la Directiva (que en el caso de prestadores de servicios de certificación españoles se concretan en la Ley 59/2003). En particular se indica que este tipo de certificados se expide a personas físicas. El certificado reconocido otorga a la firma el nivel mayor de valor jurídico en la jerarquía establecida por la Ley 59/2003, de Firma Electrónica: La firma electrónica (simple) es el conjunto de datos en forma electrónica, consignados junto a otros o asociados con ellos, que pueden ser utilizados como medio de identificación del firmante (de los datos a los que se asocia) La firma electrónica avanzada es la firma electrónica que permite identificar al firmante y detectar cualquier cambio ulterior de los datos firmados, que está vinculada al firmante de manera única y a los datos a que se refiere y que ha sido creada por medios que el firmante puede mantener bajo su exclusivo control. Es decir, que está llevada a cabo con criptografía de clave pública y con el respaldo de un certificado electrónico. La firma electrónica reconocida es la firma electrónica avanzada basada en un certificado reconocido y generada mediante un dispositivo
seguro de creación de firma. La firma electrónica reconocida tendrá respecto de los datos consignados en forma electrónica el mismo valor que la firma manuscrita en relación con los consignados en papel. Frecuentemente a la firma electrónica reconocida se la denomina también cualificada, a partir de la definición de certificado cualificado de la directiva que acabó traduciéndose como “reconocido”. Como ejemplo, podemos indicar que una firma gráfica digitalizada, incorporada a un documento, puede ser considerada firma electrónica simple. También tiene la consideración de firma electrónica simple la identificación de un usuario mediante identificativo de usuario y clave (o password), o mediante un PIN, como en el caso de las tarjetas de crédito. Una variante de firma electrónica avanzada es la que emplea criptografía de clave pública, y un código de verificación del contenido del documento, como por ejemplo la que se utiliza en el correo electrónico. En este caso, aunque el certificado utilizado no se haya obtenido tras un proceso riguroso de verificación de identidad, se siguen cumpliendo los supuestos básicos que exige la norma. El uso de sistemas criptográficos como PGP también cumple estos requisitos. Cuando la identidad se comprueba de forma rigurosa, se cumple uno de los requisitos formales del certificado reconocido, aunque no es el único. Por eso, en ocasiones pueden establecerse subniveles de firma electrónica avanzada según el rigor del prestador de
servicios de certificación (o de sus entidades de inscripción – autoridades de registro) al expedir el certificado (i.- identidad alegada, ii.- dirección de e-mail verificada, iii.- datos verificados indirectamente por vinculación con otros, iv.datos verificados indirectamente por relación preexistente, v.- aportación de documentos y evidencias de forma no presencial) Cuando se realiza verificación presencial de los datos del firmante y se cumplen otros requisitos formales, el prestador de servicios de certificación está en disposición de emitir certificados reconocidos, que son los que dan lugar a la firma electrónica reconocida. La regla general es utilizar en lo posible certificados personales (para que sean válidos en toda Europa) De entre estos, deben preferirse aquellos que en su codificación incluyan una referencia a la empresa en la que la persona presta sus servicios. Mejor todavía es emplear certificados de representante que se hayan obtenido en base a un poder notarial que restrinja su uso a firma de facturas. La Ley 59/2003, de 19 de diciembre, de Firma Electrónica regula de manera expresa los certificados electrónicos de personas jurídicas5. En el tráfico jurídico, aunque a través de una ficción, se reconoce personalidad jurídica y capacidad de obrar a las personas jurídicas, el ejercicio de tales potestades sólo puede ser
efectivo mediante la intervención de una persona física que actúa en representación de la entidad6. Pero la Ley de Firma Electrónica introduce una novedad, la posibilidad de que las personas jurídicas firmen por sí mismas quedando de esta forma vinculadas en sus operaciones realizadas mediante el uso de medios telemáticos. Para que ello sea posible y revista validez, es necesario que los datos de creación de firma sean custodiados por la persona física solicitante, cuyos datos van insertos en el certificado electrónico, que asume las responsabilidades previstas en la ley. La intervención de los representantes de las personas jurídicas es un claro ejemplo de la llamada representación necesaria. La misma deriva de la celebración del otorgamiento de un documento público el cual reconoce a un sujeto, persona física, determinado como representante legal de una persona jurídica determinada. Pues bien, la Ley 59/2003, de 19 de diciembre, de Firma Electrónica, regula los certificados de representantes (artículos 11.4, 13.3 y 23.2), cuyo contenido deberá tener mención expresa del documento público acreditativo de las facultades del firmante. El régimen jurídico aplicable a este tipo de certificados es análogo al señalado para la representación propiamente dicha por la legislación común.
5 Art. 7 Ley 59/2003, de 19 de diciembre, de Firma Electrónica 6 Art. 35/ss Código Civil
Los certificados de representante son idóneos para el uso y desarrollo de sistemas de facturación electrónica. La Ley 59/2003 de Firma Electrónica es la más reciente transposición a nuestro ordenamiento jurídico de la Directiva 1999/93/CE. En esta Ley se define como firma electrónica reconocida la firma electrónica avanzada, basada en un certificado reconocido y creada mediante un dispositivo seguro de creación de firma. Es por tanto el tipo de firma adecuado para la facturación electrónica. Cabe destacar que la Directiva 2001/115/CE solo exige firma electrónica avanzada, aunque autoriza a los países miembros a exigir la firma reconocida en el ámbito nacional. Dado que el RD 1496/2003 se publicó el 29 de noviembre y la Ley 59/2003 se publicó el 20 de diciembre, a lo largo del año 2003 estuvieron vigentes otras normas. En particular, la Orden HAC/3134/2002, de 5 de diciembre, sobre un nuevo desarrollo del régimen de facturación telemática previsto en el artículo 88 de la Ley 37/1992, de 28 de diciembre, del Impuesto sobre el Valor Añadido, y en el artículo 9 bis del Real Decreto 2402/1985, de 18 de diciembre, y la Orden HAC/1181/2003, de 12 de mayo, por la que se establecen normas específicas sobre el uso de la firma electrónica en las relaciones tributarias por medios electrónicos, informáticos y telemáticos con la Agencia Estatal de Administración Tributaría. La Orden EHA/962/2007 aclara que cualquier otra firma electrónica avanzada, basada en un certificado reconocido (de cualquier prestador de servicios de certificación europeo, con a arreglo a su normativa nacional, derivada de la Directiva 1999/93) y generada mediante un dispositivo seguro de firma (lo que el artículo 3.3 de la Ley 59/2003, de firma electrónica, denomina firma electrónica reconocida) es plenamente válida. La Orden EHA/962/2007 además deroga la Orden HAC/3134/2002. En virtud de la Orden HAC/1181/2003 son válidos los certificados que se indican en las tablas siguientes:
En la URL, www.aeat.es/normlegi/ecomercio/factcert.htm se pueden encontrar las versiones actualizadas de esta tabla. A partir del 20 de marzo de 2004, con la entrada en vigor la Ley 59/2003 de Firma Electrónica, corresponde al Ministerio de Ciencia y Tecnología (hoy, Ministerio de Industria, Turismo y Comercio), el censo de Prestadores de Servicios de Certificación. El 6 de septiembre de 2007, los PSC de este censo (disponible en https://www11.mityc.es/prestadores/busquedaPrestadores.jsp ) cuyos certificados pueden utilizarse para Facturación Electrónica son:
ANF-AC CERES CAMERFIRMA FIRMAPROFESIONAL ACCV AC ABOGACÍA CICCP ANCERT BANESTO IZENPE CATCERT
Publicada información del prestador Publicada información del prestador Publicada información del prestador. Publicada información del prestador. Publicada información del prestador. Publicada información del prestador Publicada información del prestador Publicada información del prestador Publicada información del prestador Publicada información del prestador Publicada información del prestador
IPSCA TELEFONICA EMPRESAS SERVICIO DE CERTIFICACIÓN DE LOS REGISTRADORES (SCR)
Publicada información del prestador. En estudio documentación aportada.
En estudio información adicional aportada.
NETFOCUS En estudio información adicional aportada. DIRECCIÓN GENERAL DE LA POLICÍA (DGP) Publicada información del prestador. COLEGIO OFICIAL DE ARQUITECTOS DE SEVILLA (COAS) Solicitada información adicional.
La versión más actualizada de esta tabla se encuentra en http://www.mityc.es/DGDSI/Servicios/FirmaElectronica/Prestadores/relaPrestadores.htm Además de las normas legales mencionadas, algunas normas técnicas y operativas permiten comprobar si un certificado es válido ya que cualquier certificado reconocido deberá estar codificado con la indicación de que lo es (qualified certificate flag según las normas TS 101 862 y RFC 3739). Si un PSC codifica correctamente sus certificados reconocidos, proporciona una valiosa información para permitir el procesamiento automatizado a los terceros que confían en ellos. Los PSC que expiden certificados reconocidos, además deben cumplir algunos requisitos económicos (en España) y algunas normas técnicas y operativas: • TS 101 456. Requisitos de política para PSC que expiden certificados reconocidos. • TS 102 042. Requisitos de política para PSC que expiden certificados de clave pública. Este marco amplia la posibilidad de que se puedan recibir facturas electrónicas firmadas con certificados de cualquier PSC europeo, y no solo español, ya que en el Real Decreto 1496/2003, se indica que la validez de los certificados expedidos por cualquier prestador que se ajuste al marco normativo que se deriva de la Directiva 1999/93/CE. En función del artículo 11 de esta Directiva, es posible identificar los PSC que operan en Europa a partir de este enlace: http://ec.europa.eu/information_society/eeurope/2005/all_about/security/esignatures/index_en.htm
Proyecto de Factura Electrónica de ASIMELEC • PAV-080200-2007-062
More From This UserSkip carouselIndicadores de adaptación a SEPA en España (mayo2011)Zbacktrust 22-02-11 EnxBackTrust español2
Sign up to vote on this titleUsefulNot usefulManualFacturaElectronica by Julián Inza5.0 (1)EmbedDownloadDescriptionManual sobre la Factura Electrónica que tiene en cuenta la normativa europea, especialmente española.Manual sobre la Factura Electrónica que tiene en cuenta la normativa europea, especialmente española.Interests: Types, Books - Non-fictionRead on Scribd mobile: iPhone, iPad and Android.Copyright: Attribution Non-Commercial (BY-NC)Download as PDF, TXT or read online from ScribdFlag for inappropriate contentShow moreShow less