Un portal B2B puede automatizar la consulta de crédito, la aplicación de condiciones de pago, la reserva de exposición, el estado de cobro y la descarga de facturas. No debe automatizar sin control la concesión de crédito, la eliminación de bloqueos ni una excepción que aumente el riesgo. El ERP o sistema financiero sigue siendo la fuente autorizada; el portal presenta y aplica una versión trazable de la decisión.
La experiencia correcta no consiste en mostrar «crédito disponible» como un saldo decorativo. Antes de confirmar un pedido, el portal debe saber qué cuenta será facturada, qué documentos consumen el límite, qué importe se está reservando y qué ocurrirá si el dato cambia mientras el comprador completa el checkout.
Distingue límite, exposición y disponible
- Límite de crédito: riesgo máximo aprobado para la cuenta de facturación.
- Exposición: importes que ya consumen el límite: facturas abiertas y, según política, pedidos confirmados, entregas no facturadas y reservas temporales.
- Crédito disponible: límite menos exposición y ajustes autorizados.
- Bloqueo: decisión adicional que puede impedir comprar aunque exista disponible, por ejemplo deuda vencida o revisión de riesgo.
La fórmula parece sencilla, pero el alcance debe quedar escrito. Si el límite es 100.000 EUR, hay 55.000 en facturas abiertas, 12.000 en pedidos no facturados y una reserva de 8.000, el disponible es 25.000 sólo si esos cuatro componentes comparten moneda, cuenta y momento de valoración. No sumes importes en monedas distintas sin el tipo de cambio y la fecha aprobados.
Resuelve primero la cuenta de facturación
El usuario que compra no siempre es el deudor. Una filial puede pedir y la matriz recibir la factura; varias delegaciones pueden compartir un límite, o cada una tener condiciones propias. La clave de control debe incluir al menos:
- identidad del comprador y ubicación activa;
- cuenta de pedido y cuenta de facturación;
- entidad legal del vendedor;
- mercado y moneda de crédito;
- fecha/hora y versión de la evaluación.
Microsoft Dynamics 365 señala que, en B2B, el pedido puede facturarse a la organización y utilizar su límite en vez del límite del usuario. Esa separación evita evaluar el riesgo contra la persona equivocada.
Qué dato debe mostrar el portal
Si la política permite mostrar crédito al cliente, presenta importe disponible, moneda, momento de actualización y alcance: «Disponible estimado para ACME Iberia: 25.000 EUR, actualizado a las 10:42». Explica que el importe se revalida al enviar el pedido. No expongas límite total, facturas de otras divisiones ni motivos internos de riesgo a usuarios sin permiso.
Cuando el dato está atrasado, no lo presentes como actual. Utiliza estados como actualizado, temporalmente no disponible o pendiente de validación. Un valor antiguo con apariencia definitiva es peor que un mensaje explícito.
Evita la doble utilización del disponible
Dos compradores de la misma empresa pueden confirmar pedidos al mismo tiempo. Consultar 25.000 EUR y aceptar dos pedidos de 20.000 crea una exposición de 40.000. La solución necesita una operación atómica en el sistema que gobierna el crédito:
- calcular la exposición vigente;
- crear una reserva identificada para el pedido;
- confirmar o rechazar la reserva;
- convertirla en exposición real al aceptar el pedido;
- liberarla si el checkout caduca o el pedido se cancela.
Cada reserva necesita importe, moneda, cuenta, pedido, creación, caducidad y estado. Reintentar la misma solicitud debe ser idempotente: no puede reservar dos veces por un doble clic o una respuesta perdida.
Condiciones de pago: regla, no texto libre
«30 días» es ambiguo si no se define el evento inicial. Las condiciones deben especificar:
- vencimiento desde pedido, envío, entrega o fecha de factura;
- días naturales o calendario acordado;
- ajuste por festivos y fin de semana;
- porcentaje y vencimiento de un depósito;
- descuento por pronto pago, si existe;
- métodos de pago permitidos y moneda;
- ámbito: empresa, ubicación, contrato o pedido excepcional.
Shopify documenta condiciones por ubicación de empresa, como pago inmediato, net 7–90, vencimiento tras fulfillment y fecha fija para determinados pedidos, además de depósitos. La lección funcional es que condición y fecha resultante deben quedar guardadas en el pedido; un cambio posterior en la ficha de cliente no debe reescribir pedidos existentes.
Separa pedido, pago y estado contable
No uses un único estado «pendiente». Como mínimo distingue:
| Dimensión | Estados de ejemplo |
|---|---|
| Pedido | Borrador, confirmado, bloqueado, cancelado |
| Preparación | No iniciado, parcial, completado |
| Facturación | No facturado, parcial, facturado, abonado |
| Pago | No vencido, parcialmente pagado, pagado, vencido, disputado |
| Crédito | Reservado, aprobado, rechazado, excepción pendiente |
Un pedido puede estar entregado, parcialmente facturado y con pago aún no vencido. Reducirlo a «pendiente» impide al comprador actuar y dificulta el soporte.
Qué automatizar y qué someter a aprobación
| Automatizar con reglas | Mantener bajo control financiero |
|---|---|
| Aplicar condiciones vigentes | Crear o aumentar límites |
| Calcular y reservar exposición | Levantar bloqueo por morosidad |
| Rechazar por regla objetiva | Aceptar un exceso excepcional |
| Liberar reservas caducadas | Cambiar cuenta de facturación |
| Publicar facturas contabilizadas | Emitir abonos sin documento origen |
| Enviar avisos de vencimiento | Modificar fechas ya pactadas |
Una excepción debe incluir solicitante, motivo, importe, aprobador, vigencia y efecto exacto. Evita un botón genérico «forzar pedido». La persona que aprueba debe ver exposición antes/después, deuda vencida, cuenta afectada y si la excepción vale sólo para ese pedido.
Facturas, abonos y documentos descargables
El portal debería publicar únicamente documentos contabilizados o claramente marcados como proforma. Para cada factura muestra número, entidad emisora, cuenta facturada, fecha, vencimiento, moneda, importe original, saldo pendiente, estado y pedidos/albaranes relacionados.
Un abono no es una factura negativa aislada: enlázalo al documento y motivo de origen. En pagos parciales, muestra importe aplicado y saldo restante. Si existen varias entidades legales, evita mezclar numeraciones o permitir que un usuario de una filial descargue documentos de otra.
Los PDF deben proceder del repositorio financiero autorizado o verificarse contra sus datos. No regeneres en el portal un documento con una plantilla que pueda divergir del original fiscal. Registra cada descarga sensible y aplica permisos por cuenta, ubicación y rol.
Sincronización y latencia
Crédito y cobros cambian fuera del ecommerce. Define objetivos distintos: la reserva exige respuesta sincrónica; una factura puede publicarse mediante evento; un pago por transferencia quizá llegue por conciliación posterior. Cada mensaje necesita identificador, versión, fecha del evento y fecha de recepción.
Procesa eventos de forma idempotente y tolera llegadas fuera de orden. Una actualización antigua no debe reabrir una factura ya pagada. Si falla la sincronización, conserva el último estado conocido con su antigüedad, alerta a operaciones y decide si bloquear nuevos pedidos o enviarlos a revisión.
Mensajes útiles para el cliente
No muestres «error 402» ni «crédito insuficiente» sin contexto. Indica el resultado y la acción permitida: reducir pedido, pagar facturas vencidas, usar pago inmediato, solicitar revisión o contactar con una persona. No reveles puntuaciones internas, comentarios de riesgo ni datos de otras cuentas.
Pruebas imprescindibles
- Cuenta compradora distinta de la cuenta facturada.
- Dos pedidos concurrentes que compiten por el mismo disponible.
- Reserva confirmada, caducada, cancelada y reintentada.
- Pedido justo por debajo, igual y por encima del límite.
- Deuda vencida con crédito numérico disponible.
- Condición neta, depósito, pago inmediato y excepción aprobada.
- Factura parcial, abono, pago parcial y disputa.
- Usuario sin permiso intentando acceder a otro documento.
- Eventos duplicados y fuera de orden.
- Coincidencia de importes, vencimientos y saldos entre portal y ERP.
Crédito, facturas y condiciones de pago forman parte de las capacidades que un portal B2B para distribuidores debe resolver de forma coherente.
Preguntas frecuentes
¿El disponible debe actualizarse en tiempo real?
Debe revalidarse al confirmar. Puede mostrarse una estimación anterior si se indica su hora y no se promete como reserva.
¿Superar el límite obliga a rechazar?
Depende de la política. Puede bloquear, pedir pago inmediato o iniciar aprobación, pero nunca aprobarse silenciosamente.
¿Puede el cliente cambiar sus condiciones?
No directamente. Puede solicitar revisión; finanzas decide y publica una nueva versión con vigencia.
¿Qué documento debe poder descargar?
Sólo el documento autorizado para su cuenta y rol, diferenciando factura fiscal, proforma, abono y recibo.
Fuentes primarias
- Microsoft Dynamics 365 Commerce: pagos a cuenta y límites de crédito B2B.
- Microsoft Dynamics 365 Commerce: gestión de facturas B2B.
- Shopify: condiciones de pago y depósitos B2B.
- Shopify: empresas, ubicaciones y configuración B2B.
Siguiente paso
Reúne cinco cuentas reales y documenta cuenta facturada, límite, componentes de exposición, términos, permisos de factura y ruta de excepción. Después simula dos pedidos simultáneos y una transferencia conciliada con retraso. Para ampliar el diseño del portal, consulta los recursos de CODE B2B.